Давайте разберем, как лучше отвечать на собеседованиях на вопрос: «Когда вы тестируете требования, что вы конкретно проверяете и на что опираетесь?»
Бывают проекты, особенно стартапы, где формализованных требований нет. В таких случаях часто задают вопрос: «Что вы будете делать, если на проекте нет требований?» Правильный ответ: опираться на косвенные требования. Это может быть информация из Jira и Confluence, комментарии к задачам. Также следует сравнивать продукт с конкурентами, подключать здравый смысл и использовать исследовательское тестирование.
Теперь представим, что требования всё же есть. При тестировании продукта мы опираемся на спецификации, макеты интерфейсов и техническую документацию. Важно всегда задавать вопросы аналитикам, разработчикам, заказчикам и менеджерам, а также назначать встречи для уточнения требований. В технической документации, как правило, хорошо прописаны сценарии использования, включая основные и альтернативные, диаграммы последовательности и архитектура сервиса.
На что следует опираться в первую очередь при анализе требований? Самое главное - это проверяемость. Требование должно быть таким, чтобы его можно было проверить. С этим тесно связана тестируемость (тоже самое) возможность проверить требование с помощью тестов, имея четкие входные данные и ожидаемые результаты.
Следует проверять требования на ясность, однозначность и непротиворечивость. Важно искать противоречия, нелогичность и убеждаться, что в разных разделах документа нет дублирующих или конфликтующих утверждений. Формулировки должны быть понятны для всех участников процесса.
Еще одно важное свойство - актуальность. Требования необходимо поддерживать в актуальном состоянии, так же как и тестовые модели. У каждого требования должна быть зафиксированная история изменений, за которую отвечает аналитик. Далее идет трассируемость: каждое требование должно быть покрыто как минимум одним тест-кейсом, что можно отслеживать с помощью матрицы трассировки.
Также важна измеримость, особенно для нефункциональных требований. Например, в финтехе часто встречаются требования к производительности, такие как «время выполнения интеграционного запроса не более трех секунд». Это пример количественного требования. Наконец, полнота: все аспекты функциональности должны быть описаны, без упущений или недостаточной детализации.
Свойств у качественных требований много: полнота, однозначность, непротиворечивость, необходимость. Я рекомендую выделить для себя ключевые характеристики и составить их список. Даже если у вас нет большого опыта, главное, понимать каждое свойство и уметь объяснить его на примерах.