Ответ
Участие тестировщика на этапе формирования идеи (пресейл, discovery) критически важно для построения качественного продукта. На своем опыте я видел, как это помогает:
- Сформулировать проверяемые требования: Я задаю уточняющие вопросы, чтобы размытые пожелания превратились в конкретные, тестируемые критерии приемки (Acceptance Criteria). Например, для функции «быстрый поиск» мы сразу определяем метрики отклика (например, < 2 секунд).
- Выявить риски и «узкие места» тестирования: Я сразу оцениваю, насколько идея тестируема. Если планируется интеграция со сторонним API с нестабильным SLA, я предлагаю на этапе архитектуры заложить моки и заглушки для независимого тестирования нашего функционала.
- Спроектировать тестовое покрытие «с нуля»: Мы можем начать проектировать тест-кейсы и чек-листы параллельно с написанием технического задания, что экономит время на этапе активной разработки.
- Предотвратить дорогостоящие дефекты: Ранний взгляд со стороны QA позволяет найти логические противоречия или потенциальные проблемы с юзабилити до того, как на их реализацию потрачены ресурсы разработки.
Конкретный пример: На одном из проектов на этапе обсуждения идеи чат-бота я обратил внимание, что в требованиях не было описано поведение при сетевых сбоях. В итоге мы сразу дополнили ТЗ сценариями повторных попыток отправки и понятными сообщениями об ошибках для пользователя, что сэкономило неделю на переделках позже.
Ответ 18+ 🔞
Да ты послушай, какая история! Вроде бы тестировщик — это тот чувак, который приходит, когда всё уже написано, и начинает всё ломать. Ан нет, ёпта! Если его позвать в самом начале, когда идеи ещё витают в воздухе, а требования — это просто набор хотелок в стиле «сделайте красиво», то это вообще другой уровень работы получается.
Представь, сидят менеджеры, архитекторы, такие довольные, рисуют квадратики и стрелочки. «Будет у нас тут кнопочка, нажмёшь — и всё быстро найдётся!» А я, как хитрая жопа, сразу врубаюсь: «Слушайте, а что такое "быстро"? Это за секунду, за две или пока чайник закипит?» И вот уже вместо размытой хуйни у нас в документации чётко написано: «Поиск должен отрабатывать менее чем за 2 секунды в 95% случаев». Это и есть проверяемое требование, а не пиздопроебибна какая-то.
Или ещё момент — сразу видно, где нас ждёт пиздец. Говорят: «Интегрируемся с внешним сервисом Яндекса, там карты». А у меня сразу волнение ебать. А если у них API ляжет? Наше всё тоже встанет? Так давайте сразу в архитектуре пропишем заглушки, чтобы наш функционал тестировать независимо от их перебоев. Экономия нервов — овердохуища.
Самое кайфовое, что можно сразу, параллельно с написанием ТЗ, накидывать чек-листы и тестовые сценарии. Не потом, в аврале, когда код уже готов, а заранее. Чувак, это же как собрать мебель по инструкции, а не пытаться понять, куда эту хуйню с винтом прикрутить, когда половина уже собрана.
Вот тебе реальный случай, я сам от себя охуел. Обсуждаем мы чат-бота для банка. Всё красиво: вопросы, ответы, умный такой. А я спрашиваю: «А что будет, если у пользователя интернет сдохнет в момент отправки сообщения? Или если наш сервис на пять секунд упадёт?» Тишина. В требованиях про это — ни хуя. В итоге мы сразу дописали в ТЗ: бот должен делать три попытки переотправки, а если не вышло — показывать человеческое сообщение «Что-то пошло не так, попробуйте позже». Знаешь, сколько это времени сэкономило? Целую неделю переделок после релиза! А так — всё было предусмотрено сразу.
Короче, вывод простой: зовите тестировщика не тогда, когда уже всё готово и пахнет жареным, а когда только-только начинаете думать, что же будем готовить. Он сразу увидит, где в рецепте говна добавлено, и спасёт всех от несварения.