Анализ требований (Requirements Analysis) — это фундамент QA. Если требования плохие, то даже идеальный код не спасёт: вы проверите «не то» и «не так».

Вот как это выглядит в работе QA-инженера по шагам:

1. Роли и артефакты
Вы работаете с:
— Бизнес-требованиями (что хотим получить).
— Функциональными требованиями (как система должна работать).
— Макетами/дизайном (как это выглядит).
— User Stories и Acceptance Criteria (критерии готовности).

2. Что именно анализируем?
QA смотрит на текст как «адвокат дьявола»:
— Полнота — описаны ли все сценарии? (Что при пустом поле? Что при обрыве сети?)
— Однозначность — нет ли двойных трактовок («быстрый ответ» — это 1 сек или 3 сек?).
— Непротиворечивость — не пересекаются ли требования с другими модулями?
— Тестируемость — можно ли это объективно проверить? (Если написано «красивый интерфейс» — это не тестируемо. Если «кнопка #FF0000» — тестируемо).
— Реалистичность — выполнимо ли это в текущих сроках и стеке?

3. Основные инструменты (техники)
— Mind Maps — рисуете связи, чтобы не упустить побочные эффекты.
— Разбор пограничных случаев (Edge Cases): например, ввод 9999 символов, нулевая сумма, дата 29 февраля.
— Применение техник эквивалентности: деление диапазонов на классы (валидные/невалидные) ещё до старта разработки.
— Составление вопросников: по шаблону “Что если…” (What-If Analysis).

4. Практические действия
На практике вы:
— Участвуете в Refinement / Grooming (обсуждение задач до спринта).
— Пишете уточняющие комментарии прямо в задаче (Jira/Confluence).
— Создаёте декомпозицию: разбиваете одну большую фичу на десятки проверяемых пунктов.
— Формируете тестовые оракулы: определяете, где брать эталонный результат (БД, калькулятор, старый сервис).

5. Главная «суперсила» QA здесь
— Сдвиг влево (Shift Left) — найти ошибку на этапе «бумажки» стоит в 100 раз дешевле, чем на проде.
— Вы страхуете разработчика: если он пишет код по плохому ТЗ, он переделает его 3 раза. Вы экономите время всей команды.

Типичные ошибки джуниора:
— Сразу открыть приложение и начать кликать (исследовательское — это позже).
— Игнорировать нефункциональные требования (производительность, безопасность, юзабилити).

Ваш главный вопрос на встречах:

«А что именно должно произойти, если…?» — и фиксировать ответ прямо в задаче.