С какими типами требований вы работали
Что проверяют
Различаете ли вы уровни требований и умеете ли тестировать сам документ, а не только собранную по нему систему. По ответу видно, работали ли вы в проекте с внятной постановкой или привыкли выяснять всё в переписке.
Как отвечать
Начните с уровней и дайте к каждому пример.
- бизнес-требования: зачем всё это компании, какую задачу решает продукт;
- пользовательские: сценарии и истории с критериями приёмки, то есть что человек хочет сделать;
- функциональные: что именно система обязана делать, включая правила, ограничения и поведение при ошибках;
- нефункциональные: время отклика под заданной нагрузкой, доступность, безопасность, совместимость, локализация, доступность интерфейса для людей с ограничениями;
- отдельные группы: требования к интерфейсу и макеты, требования к данным и миграции, требования законодательства и внутренних регламентов.
Дальше про формы, в которых они приходили: постановка от аналитика, история в трекере, контракт API, сценарий на языке примеров, макет. И про свойства хорошего требования: однозначность, полнота, непротиворечивость и главное проверяемость.
Полезно сказать, что делаете, когда требований нет: сверяетесь с аналогами и здравым смыслом, фиксируете допущения письменно и просите подтвердить.
Где спотыкаются
Знают только деление на функциональные и нефункциональные и не могут сказать, откуда требование взялось и кто его подтверждает. Тестировщик без этой картины проверяет форму, а не задачу пользователя.
Второе: оставляют нефункциональные требования в виде пожеланий. «Должно работать быстро» не проверяется: нужны число, условия и окружение, иначе спор о том, достаточно ли быстро, начнётся на приёмке.
Третье: не проверяют постановку до разработки. Кейсы пишутся по документу дословно, противоречие вскрывается на прогоне, когда переделка стоит дороже всего. Туда же относится незафиксированное изменение требования: в дефекте начинается спор, баг это или так и задумано.