Анализ требований для тестирования

Требования нужны не для формального согласования, а для общего понимания поведения системы. QA читает требования как будущий пользователь, инженер и человек, которому нужно доказать, что сценарий работает в понятных границах.

Что важно понять

• Ясность: можно ли однозначно понять ожидаемое поведение.
• Полноту: описаны ли ошибки, пустые состояния, ограничения, права и граничные случаи.
• Проверяемость: можно ли объективно сказать, что требование выполнено.
• Согласованность: не конфликтует ли требование с существующим продуктом и соседними задачами.

Рабочий порядок

1. Выделите основной пользовательский сценарий и альтернативные ветки.
2. Найдите термины без определения и числа без единиц измерения.
3. Сформулируйте вопросы до разработки или как можно раньше в работе над задачей.
4. Преобразуйте ответы в критерии приемки и тест-идеи.

Что отдавать команде

• Список вопросов к требованиям.
• Уточнённые acceptance criteria.
• Набор тест-идей, привязанных к конкретным правилам.

Частые провалы

• Тестировать только счастливый путь, потому что он единственный описан.
• Принимать неоднозначный текст за понятный, если команда не спорит вслух.
• Хранить вопросы в личных заметках вместо общего рабочего пространства.

Практика

Откройте любую задачу и перепишите её критерии приемки в формате дано / когда / тогда. Если какой-то блок не получается заполнить, значит требованию нужен вопрос.