Ответ
Участие тестировщика на этапе формирования идеи (пресейл, discovery) критически важно для построения качественного продукта. На своем опыте я видел, как это помогает:
- Сформулировать проверяемые требования: Я задаю уточняющие вопросы, чтобы размытые пожелания превратились в конкретные, тестируемые критерии приемки (Acceptance Criteria). Например, для функции «быстрый поиск» мы сразу определяем метрики отклика (например, < 2 секунд).
- Выявить риски и «узкие места» тестирования: Я сразу оцениваю, насколько идея тестируема. Если планируется интеграция со сторонним API с нестабильным SLA, я предлагаю на этапе архитектуры заложить моки и заглушки для независимого тестирования нашего функционала.
- Спроектировать тестовое покрытие «с нуля»: Мы можем начать проектировать тест-кейсы и чек-листы параллельно с написанием технического задания, что экономит время на этапе активной разработки.
- Предотвратить дорогостоящие дефекты: Ранний взгляд со стороны QA позволяет найти логические противоречия или потенциальные проблемы с юзабилити до того, как на их реализацию потрачены ресурсы разработки.
Конкретный пример: На одном из проектов на этапе обсуждения идеи чат-бота я обратил внимание, что в требованиях не было описано поведение при сетевых сбоях. В итоге мы сразу дополнили ТЗ сценариями повторных попыток отправки и понятными сообщениями об ошибках для пользователя, что сэкономило неделю на переделках позже.