Ответ.

Тестирование требований — важный этап ручного тестирования, потому что недочеты здесь приводят к дорогим ошибкам в будущем.

История вопроса:

На ранних этапах разработки требования к продукту фиксируются в виде документов (ТЗ, спецификации). Их неправильное или неполное оформление порождает множество проблем на этапе реализации и тестирования.

Проблема:

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

Решение:

Ручное тестирование требований включает:

Внимательный аудит требований на полноту, ясность и непротиворечивость
Составление уточняющих вопросов аналитикам и бизнес-заказчикам
Фиксацию всех предполагаемых вариантов использования (positive/negative cases)
Применение техник анализа требований: таблицы согласованности, матрицы трассируемости, чек-листы для требований

Ключевые особенности:

Нахождение противоречий и «дырок» — выявление несостыковок и ситуаций, не отражённых в требованиях
Активная коммуникация с аналитиками и командой — уточнение деталей, разъяснение формулировок
Формирование четких, тестируемых требований — требования должны быть однозначными, реализуемыми и измеримыми

Вопросы с подвохом.

Что значит «требование является тестируемым»?

Тестируемое требование — это такое требование, по которому можно точно сказать, выполнено оно в продукте или нет. В нем не допускаются абстракции, общие фразы и неясные параметры.

Можно ли считать требования качественными, если они понятны только авторам?

Нет. Качественные требования должны быть однозначно поняты всеми участниками команды (разработкой, тестировщиками, аналитиками, бизнесом).

В обязанность тестировщика входит дописывать или исправлять требования?

Нет, тестировщик выявляет проблемы и сообщает о них ответственным, но не должен самостоятельно переписывать требования.

Типовые ошибки и анти-паттерны

Принимать требования на веру, не задавая уточняющих вопросов
Игнорировать мелкие нестыковки и допущения
Не документировать найденные «дыры» и противоречия, надеясь, что «разработчики разберутся»

Пример из жизни

Негативный кейс

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

Плюсы:

Сэкономлено время на этапе написания требований

Минусы:

Много правок на более поздних этапах
Высокие затраты на багфиксинг
Недовольство заказчика

Позитивный кейс

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