Спецификации и документация
Документные артефакты, которые пишет аналитик — SRS, ТЗ/ЧТЗ, ГОСТ 19 и 34, потоки use case, user story по INVEST, критерии приёмки на Gherkin, DoR/DoD и декомпозиция историй.
11 вопросов
JuniorТеорияОчень частоЧто означает INVEST и как распознать плохую user story?
Что означает INVEST и как распознать плохую user story?
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable. Хорошая story — маленький независимый срез с явной пользой для пользователя и тестируемыми критериями. Плохая не несёт пользы, слишком велика для спринта или непроверяема — непонятно, когда она готова.
Типичные ошибки
- ✗Писать story как технические задачи без пользы для пользователя
- ✗Делать story слишком большой, чтобы закрыть за один спринт
- ✗Опускать тестируемые критерии приёмки, из-за чего «готово» неясно
Уточняющие вопросы
- →Какая буква INVEST чаще всего нарушается на практике?
- →Как свойство «Negotiable» меняет то, как вы пишете story?
JuniorТеорияЧастоКакие документы создаёт системный аналитик и кто потребитель каждого?
Какие документы создаёт системный аналитик и кто потребитель каждого?
Аналитик создаёт артефакты требований — SRS или ТЗ, спецификации use case и user story, API-контракты, модели данных и диаграммы BPMN и UML. Разработчики строят по спецификациям, QA выводит тесты из критериев приёмки, заказчик подписывает ТЗ, а РП отслеживает объём.
Типичные ошибки
- ✗Называть только ТЗ, забывая контракты, модели данных и диаграммы
- ✗Считать, что у каждого документа одна и та же аудитория
- ✗Думать, что QA работает по исходному коду, а не по критериям приёмки
Уточняющие вопросы
- →Какой из этих артефактов подписывает заказчик?
- →Как сокращается набор документов в Agile-команде?
JuniorТеорияЧастоЧто такое DoR, DoD и критерии приёмки и кто владелец каждого?
Что такое DoR, DoD и критерии приёмки и кто владелец каждого?
DoR (Definition of Ready) — чек-лист, которому story должна соответствовать до взятия в спринт; DoD (Definition of Done) — чек-лист готовности работы. Оба принадлежат команде. Критерии приёмки — условия по конкретной story, которые пишет аналитик или PO, а проверяет QA.
Типичные ошибки
- ✗Путать общий для команды DoD с критериями приёмки по конкретной story
- ✗Отдавать владение DoR/DoD заказчику, а не команде
- ✗Путать, когда проверяется DoR, а когда DoD
Уточняющие вопросы
- →Почему DoD задан для всей команды, а критерии приёмки — по каждой story?
- →Что происходит в спринте, если story взяли без соответствия DoR?
MiddleДизайнЧастоUser story слишком велика, чтобы закрыть её за один спринт — «Как пользователь, я могу управлять своими заказами». Команда хочет её раздробить, но плохое дробление создаёт фрагменты, которые сами по себе не несут ценности или не тестируются. Какие паттерны дробления вы применяете — по шагу процесса, по бизнес-правилу, по CRUD-операции, сначала happy path потом альтернативы, по вариации данных — и какие дробления неверны? Объясните, как держать каждый срез вертикальным и самостоятельно ценным и почему дробление по слою архитектуры (story на UI, затем на бэкенд, затем на БД) — классическая ошибка.
User story слишком велика, чтобы закрыть её за один спринт — «Как пользователь, я могу управлять своими заказами». Команда хочет её раздробить, но плохое дробление создаёт фрагменты, которые сами по себе не несут ценности или не тестируются. Какие паттерны дробления вы применяете — по шагу процесса, по бизнес-правилу, по CRUD-операции, сначала happy path потом альтернативы, по вариации данных — и какие дробления неверны? Объясните, как держать каждый срез вертикальным и самостоятельно ценным и почему дробление по слою архитектуры (story на UI, затем на бэкенд, затем на БД) — классическая ошибка.
Дробите так, чтобы срез был вертикальным и давал ценность сам — по шагу, CRUD-операции или вариации правила. Срез маленький, независимый и тестируемый. Неверно дробить горизонтально по слоям (UI, бэкенд, БД) — слой нельзя поставить или протестировать один.
Типичные ошибки
- ✗Дробить по слоям на отдельные story UI, бэкенда и БД
- ✗Создавать срезы без самостоятельной пользы для пользователя
- ✗Жертвовать тестируемостью или независимостью ради уменьшения story
Уточняющие вопросы
- →Чем дробление по бизнес-правилу отличается от дробления по CRUD?
- →Насколько маленький срез уже слишком мал?
MiddleТеорияЧастоЧто такое ТЗ, что такое ЧТЗ и чем они различаются по аудитории и глубине?
Что такое ТЗ, что такое ЧТЗ и чем они различаются по аудитории и глубине?
ТЗ (техническое задание) — верхнеуровневое соглашение заказчика и подрядчика о том, что делает система, для заказчика и руководства. ЧТЗ (частное техническое задание) — спецификация по подсистемам для разработчиков, с алгоритмами и экранами. ЧТЗ глубже и техничнее.
Типичные ошибки
- ✗Путать, какой документ глубже — деталь в ЧТЗ, а не в ТЗ
- ✗Считать, что у ТЗ и ЧТЗ одна аудитория
- ✗Принимать ТЗ или ЧТЗ за документ тестов или журнал изменений
Уточняющие вопросы
- →Кто подписывает ТЗ, а кто ЧТЗ?
- →На небольшом продукте когда можно обойтись без ЧТЗ?
MiddleДизайнЧастоВам нужно написать постановку задачи для совершенно нового экрана UI — страницы профиля клиента. Разработчики будут его делать, а QA тестировать прямо по вашему документу, и вы хотите ноль уточняющих вопросов назад. Какие разделы вы включаете, чтобы обеим ролям хватало всего? Учтите цель экрана и актора; вёрстку и каждое поле с типом, валидацией и значением по умолчанию; состояния экрана (пустое, загрузка, ошибка, заполнено); каждое действие и куда оно ведёт; права доступа; источник данных для каждого поля (API или сущность); нефункциональные ограничения; и критерии приёмки, которые проверит QA. Укажите, что вы намеренно опускаете и почему.
Вам нужно написать постановку задачи для совершенно нового экрана UI — страницы профиля клиента. Разработчики будут его делать, а QA тестировать прямо по вашему документу, и вы хотите ноль уточняющих вопросов назад. Какие разделы вы включаете, чтобы обеим ролям хватало всего? Учтите цель экрана и актора; вёрстку и каждое поле с типом, валидацией и значением по умолчанию; состояния экрана (пустое, загрузка, ошибка, заполнено); каждое действие и куда оно ведёт; права доступа; источник данных для каждого поля (API или сущность); нефункциональные ограничения; и критерии приёмки, которые проверит QA. Укажите, что вы намеренно опускаете и почему.
Опишите цель и актора; каждое поле с типом, валидацией и значением по умолчанию; состояния экрана; цель каждого действия; права доступа; источник данных полей. Добавьте ограничения и критерии приёмки для QA. Вопросы убирает точность, а не визуал.
Типичные ошибки
- ✗Отдавать макет без правил полей, валидации и состояний
- ✗Описывать только заполненное состояние, опуская ошибки и пустое
- ✗Оставлять источник данных или критерии приёмки на догадки других
Уточняющие вопросы
- →Как задать валидацию поля, не диктуя интерфейс?
- →Какое состояние экрана чаще всего забывают в спецификации?
MiddleТеорияЧастоЧто такое основной, альтернативный и исключительный потоки use case и как понять, что нашли все?
Что такое основной, альтернативный и исключительный потоки use case и как понять, что нашли все?
Основной поток — happy path, где всё успешно. Альтернативные потоки — другие валидные пути к цели, например картой или кошельком. Исключительные потоки — блокирующие сбои, например отклонённый платёж. Полноту проверяют, проходя каждый шаг и спрашивая, что ещё возможно.
Типичные ошибки
- ✗Называть пути сбоя «альтернативными», а не «исключительными» потоками
- ✗Документировать только happy path и пропускать остальное
- ✗Считать, что у use case всегда ровно три потока
Уточняющие вопросы
- →Где размещается предусловие относительно этих потоков?
- →Как исключительные потоки ложатся на негативные тест-кейсы?
MiddleТеорияИногдаКак писать критерии приёмки в нотации Gherkin и когда Given/When/Then — неподходящий формат?
Как писать критерии приёмки в нотации Gherkin и когда Given/When/Then — неподходящий формат?
Gherkin описывает каждый критерий сценарием — Given (предусловие), When (действие), Then (ожидаемый результат), один сценарий на поведение, с конкретными данными. Формат не подходит для критериев не о поведении — цифр нефункциональных требований или простых ограничений, где Given/When/Then лишь добавляет шум.
Типичные ошибки
- ✗Складывать несколько поведений в один сценарий Given/When/Then
- ✗Втискивать нефункциональные или layout-критерии в Gherkin
- ✗Писать сценарии с абстрактными данными вместо конкретных примеров
Уточняющие вопросы
- →Как Scenario Outline снижает повтор в похожих кейсах?
- →Где живут нефункциональные критерии, если не в Gherkin?
MiddleТеорияИногдаЧто такое SRS, из каких разделов состоит и когда его пишут вместо бэклога историй?
Что такое SRS, из каких разделов состоит и когда его пишут вместо бэклога историй?
SRS (Software Requirements Specification) — единый документ всех требований: функциональные и нефункциональные требования, интерфейсы и ограничения. Его выбирают вместо бэклога историй для работ фиксированного объёма по договору или ГОСТ, подписываемых заранее.
Типичные ошибки
- ✗Приравнивать SRS к простому выгруженному бэклогу
- ✗Считать, что SRS содержит только нефункциональные требования
- ✗Применять SRS для изменчивого Agile-объёма вместо фиксированного
Уточняющие вопросы
- →Какой раздел SRS фиксирует требования к внешним интерфейсам?
- →Как не дать SRS устареть после подписания?
SeniorДизайнИногдаВаша спецификация экрана спринт за спринтом порождает вопросы разработчиков — каждые пару часов кто-то пишет уточнить поле, правило или граничный случай, а QA заводит баги, которые оказываются незаписанными требованиями. Вы решаете переработать то, как вы пишете спецификации, а не только этот документ. Что вы добавляете, что убираете и как перестраиваете спецификацию, чтобы вопросы прекратились? Разберите корневые причины неоднозначности, как сделать каждое требование тестируемым и трассируемым, какая деталь — сигнал, а какая — шум, и как проверить, что спецификация полна, до передачи.
Ваша спецификация экрана спринт за спринтом порождает вопросы разработчиков — каждые пару часов кто-то пишет уточнить поле, правило или граничный случай, а QA заводит баги, которые оказываются незаписанными требованиями. Вы решаете переработать то, как вы пишете спецификации, а не только этот документ. Что вы добавляете, что убираете и как перестраиваете спецификацию, чтобы вопросы прекратились? Разберите корневые причины неоднозначности, как сделать каждое требование тестируемым и трассируемым, какая деталь — сигнал, а какая — шум, и как проверить, что спецификация полна, до передачи.
Бейте по корню неоднозначности — меняйте расплывчатую прозу на конкретные правила, явные состояния и валидацию полей. Добавьте тестируемые критерии приёмки и опишите каждый поток, включая ошибки. Уберите повтор фона и не-требования. Проверяйте её с разработчиком и QA до передачи.
Типичные ошибки
- ✗Отвечать на неоднозначность прозой вместо конкретных правил
- ✗Винить разработчиков вместо устранения пробелов спецификации
- ✗Пропускать разбор спецификации с разработчиком и QA до передачи
Уточняющие вопросы
- →Как сделать требование трассируемым к его источнику?
- →Что сигналит, что деталь — шум, а не требование?
JuniorТеорияРедкоЧто такое ГОСТ 19 и ГОСТ 34 и какой из них к чему применяется?
Что такое ГОСТ 19 и ГОСТ 34 и какой из них к чему применяется?
ГОСТ 19 (ЕСПД) описывает документы о самой программе — её описание, руководства оператора и программиста. ГОСТ 34 описывает автоматизированную систему целиком — её техническое задание и пояснительные записки. ГОСТ 34 берут для полной АС, ГОСТ 19 — для отдельной программы.
Типичные ошибки
- ✗Путать, какой стандарт описывает программу, а какой — систему целиком
- ✗Считать ГОСТ 19 и ГОСТ 34 взаимозаменяемыми
- ✗Путать их с ISO или современными API-стандартами
Уточняющие вопросы
- →Какой документ ГОСТ 34 называет техническим заданием?
- →Когда для современного продукта ГОСТ вообще не берут?
