Требования: вопросы для собеседования QA

Definition of Ready — набор критериев, при которых задача готова к взятию в работу: понятные требования, дизайны, оценка, заведённые тестовые сценарии, разрешённые зависимости.

Definition of Done — критерии завершённости: код написан, проверен на ревью, покрыт тестами, прошёл QA, документация обновлена.

Из практики: чёткие DoR и DoD сокращают переделки и недопонимание. QA активно участвует в формулировке обоих, особенно DoD.

Acceptance criteria — это условия, при которых фича считается выполненной. Обычно формулируются в стиле Given/When/Then или просто списком чек-пунктов.

Пишет PM или аналитик совместно с командой (включая QA). QA — естественный голос для уточнения граничных случаев.

Из практики: чёткие AC — основа хорошей фичи. Если AC размыты — будут переделки и споры на этапе приёмки.

Бизнес-требования (зачем делаем), пользовательские (что пользователь хочет получить), функциональные (что система делает), нефункциональные (как делает: производительность, безопасность, юзабилити), переходные (что нужно для перехода со старой системы на новую).

Уровни идут сверху вниз: бизнес → пользовательские → функциональные/НФТ. Каждый уровень детализирует предыдущий и должен трассироваться обратно.

Из практики: главная ошибка — начинать с функциональных, не зафиксировав бизнес-цель. Получается продукт, который никому не нужен.

Функциональные требования (ФТ) описывают, ЧТО система делает: «пользователь может оплатить заказ картой». Нефункциональные (НФТ) описывают, КАК она это делает: «p95 ответа платёжного API < 500 мс при 100 RPS».

ФТ — про поведение и сценарии. НФТ — про качество: производительность, безопасность, юзабилити, надёжность, поддерживаемость, переносимость.

Из практики: НФТ — слабое место аналитика. Их часто пишут как «должно быть быстро» вместо измеримых критериев.

FURPS: Functionality, Usability, Reliability, Performance, Supportability. FURPS+ добавляет: Design constraints, Implementation, Interface, Physical. Альтернатива — ISO 25010 (8 характеристик качества).

Чаще всего описываю: производительность (latency, throughput, p95/p99), безопасность (методы аутентификации, шифрование, аудит), доступность (SLA, RTO/RPO), юзабилити (для каких устройств/локалей).

Из практики: НФТ удобно собирать по чек-листу — иначе всегда что-то забудешь. У меня есть свой шаблон НФТ под каждый тип системы.

Переходные требования — то, что нужно сделать ОДНОКРАТНО для перехода со старой системы на новую: миграция данных, конвертация, обучение пользователей, временные интеграции, параллельная работа двух систем.

Пример: при миграции CRM нужно перенести 5 млн контактов, обучить 200 менеджеров и месяц поддерживать оба интерфейса. Это — переходные требования, они не остаются в продакшене после внедрения.

Из практики: переходные требования часто оценивают по остаточному принципу и срывают cutover. На них уходит 20–30% бюджета крупных проектов.

User Story — короткое описание потребности с точки зрения пользователя по формуле: «Как <роль>, я хочу <действие>, чтобы <выгода>». Цель — единица обсуждения и работы, а не полная спецификация.

Пример: «Как менеджер продаж, я хочу видеть рейтинг клиентов по сумме за квартал, чтобы планировать звонки на следующий месяц». Дальше — критерии приёмки (AC) и обсуждение реализации.

Из практики: формула «Кто/Что/Зачем» защищает от story без бизнес-смысла. Если «зачем» пустое — это фича, а не story.

Acceptance Criteria (AC) — конкретные проверяемые условия, при которых эта user story считается выполненной. Привязаны к одной story. Часто в формате Given/When/Then (Gherkin) или списка чек-боксов.

Definition of Done (DoD) — общий чек-лист команды для ВСЕХ задач: код-ревью пройдено, тесты написаны, документация обновлена, на стейдже задеплоено. Не привязан к конкретной story.

Из практики: AC отвечает «что именно работает в этой фиче», DoD — «по каким стандартам сделана любая работа». Это разные документы и разные владельцы (PO vs команда).

INVEST: Independent (не зависит от других), Negotiable (можно обсуждать реализацию), Valuable (есть ценность), Estimable (можно оценить), Small (помещается в спринт), Testable (есть критерии проверки).

Хорошая story — это не полная спецификация, а приглашение к разговору. Если её нельзя обсудить и нельзя проверить — это не story.

Из практики: чаще всего страдает Small и Independent. Большая story дробится на серии или сплитуется по сценариям, а не по слоям (бэк/фронт).

User Story Map (Джефф Паттон) — двумерная карта: по горизонтали путь пользователя (backbone верхнего уровня), по вертикали — story внутри каждого шага, отсортированные по приоритету. Релизы режутся горизонтальными полосами.

Помогает увидеть систему целиком, выделить тонкий MVP-срез по всему пути пользователя, а не «зафигачить весь backlog по одному модулю».

Из практики: USM — лучшее лекарство от backlog-портянки. Команда видит картину и легче приоритизирует.

Use Case — текстовый сценарий взаимодействия актора с системой для достижения цели. В отличие от User Story, описывает поток шагов, альтернативы и исключения.

Типовые разделы: название, цель, актор(ы), предусловия, основной поток, альтернативные потоки, исключения, постусловия, особые требования. Формат — Cockburn casual или fully dressed.

Из практики: fully dressed use case оправдан в крупных проектах с регуляторкой. В стартапах достаточно casual: цель, актор, шаги, альтернативы.

User Story — короткая «карточка для разговора», 1–3 строки + AC. Use Case — детальный сценарий с шагами, альтернативами и исключениями, обычно несколько страниц.

Story — артефакт Agile, оптимизирована под итеративную работу и обсуждение. Use Case — артефакт RUP/Waterfall, оптимизирован под полную спецификацию.

Из практики: они не взаимоисключающие. На крупных фичах сначала пишу Use Case (общая картина), потом дроблю в user stories для спринта.

SRS (Software Requirements Specification) — полная спецификация требований к ПО: функциональные, нефункциональные, интерфейсы, ограничения. Стандартный шаблон — IEEE 830.

Применяется в Waterfall, при фиксированном scope, в гос/банковских/медицинских проектах, при аутсорсе с фиксированной ценой. В Agile-проектах SRS как монолитный документ заменяют живым набором story и спецификаций.

Из практики: даже в Agile-команде на крупных интеграциях имеет смысл писать «лёгкий SRS» — это снимает споры на стыках команд.

ГОСТ 19 — серия стандартов на программные продукты (как отдельные программы). Описывает структуру ТЗ, спецификации, описание программы и эксплуатационной документации.

ГОСТ 34 — серия стандартов на автоматизированные системы (АС): стадии и этапы создания, состав документов на каждой стадии. Это более широкий комплекс: оборудование, ПО, оргобеспечение.

Из практики: ГОСТ 34 чаще встречается в госконтрактах и крупных корпоративных АС, ГОСТ 19 — в проектах на разработку конкретного ПО. Многие проекты используют оба, разделяя документы.

Стандартный список: атомарность, полнота, непротиворечивость, корректность, ясность (однозначность), верифицируемость (тестируемость), реализуемость, трассируемость, приоритезированность, актуальность.

Самые часто нарушаемые — однозначность и тестируемость. «Система должна быть удобной» — не однозначно и не тестируемо. «p95 < 300 мс на пути checkout» — да.

Из практики: проверяю требование вопросом «какой тест-кейс из этого напишет тестировщик?». Если не получается — переписываю.

Верификация требований — «делаем ли мы продукт правильно». Проверка, что требования согласованы, полны, корректны по форме (статический анализ, ревью).

Валидация требований — «делаем ли мы правильный продукт». Проверка, что требования соответствуют реальной потребности бизнеса/пользователя (демо прототипа, проверка на сценариях, пользовательские тесты).

Из практики: верификацию делает аналитик с командой, валидацию — с заказчиком/пользователем. Пропуск валидации = красивый ТЗ под ненужный продукт.

Поле: тип данных, обязательность, маска/формат, длина, валидация (правила + тексты ошибок), значение по умолчанию, видимость по условиям, доступность для редактирования. Кнопка: состояния (active/disabled/loading), действия при клике, условия видимости. Форма: набор полей, порядок, валидация на сабмит, поведение при успехе/ошибке.

Удобно делать единый шаблон описания UI-элементов проекта, чтобы разработчик и тестировщик не угадывали.

Из практики: 80% дефектов в UI — из-за непрописанных edge-cases: пустые значения, длинные строки, спецсимволы, повторное нажатие, потеря сети.

Использую набор техник: чек-листы (для НФТ, безопасности, локализации), вопросы из «5W+1H», ревью с разработчиками и тестировщиками, прототипирование на спорных местах, проверка крайних случаев (пустые, максимальные, отрицательные значения).

Особенно помогает «inverse thinking»: что должно произойти, чтобы это требование сломалось? Какие сценарии его обходят?

Из практики: дешевле всего найти проблемы на ранних этапах через walk-through с командой. Каждый смотрит со своей стороны и видит разные риски.

Сначала проверяю — это реальное противоречие или терминологическое. Если терминологическое — фикс через глоссарий. Если реальное — выношу на принятие решения тем, кто отвечает за бизнес-цель (PO/спонсор), с двумя-тремя вариантами и их последствиями.

Фиксирую решение в decision log с автором и обоснованием. Обновляю все артефакты, на которые противоречие повлияло.

Из практики: молча выбрать одну сторону = впоследствии переделывать. Лучше потратить день на эскалацию, чем неделю на переделку.

Принципы: не ломать существующих потребителей. Только добавлять (additive changes) — новые поля, новые эндпоинты с версией. Удаление и переименование — через deprecation: помечаем устаревшим, держим N версий, потом убираем.

В требованиях явно прописываю: какие потребители использует фичу/контракт, какая стратегия миграции, какой период deprecation, как уведомляются потребители.

Из практики: компромисс обычно между скоростью развития и стабильностью. Чёткое политика версионирования снимает споры в каждом релизе.

DoR (Definition of Ready) — чек-лист готовности задачи ко входу в спринт: ясная цель, AC, оценка, нет блокеров. Защищает команду от «сырого» backlog.

DoD (Definition of Done) — общий чек-лист «когда задача считается завершённой»: код, тесты, ревью, деплой на стейдж, обновлённая документация. Один на команду.

AC (Acceptance Criteria) — конкретные проверяемые условия выполнения этой user story. Привязаны к одной задаче.

Из практики: команды путают DoD и AC. DoD — общие стандарты ВСЕХ задач, AC — функционал ЭТОЙ задачи.

DoR — чек-лист готовности задачи ко входу в спринт. Типовые пункты: ясная цель, AC написаны, оценка дана, зависимости известны, без блокеров, описаны UI и интеграции, при необходимости — макеты.

Нужен, чтобы команда не брала «сырое» в работу. Иначе спринт ломается на полпути: «а это как делать?».

Из практики: жёсткий DoR пугает PO («слишком строго»), мягкий DoR не работает. Лучшее — короткий чек-лист на 5–7 пунктов, который реально проверяется на refinement.