«Тут еще нечего тестировать!» - говорит разработчик, когда я захожу посмотреть, как продвигается задача. Мол, дай спокойно код написать, еще успеешь проверить. 😄

Но зачем ждать готовую сборку, если часть проблем можно найти еще до того, как написана первая строчка кода?

Расскажу на примере.

Был у меня проект, где тестировщиков подключали строго после готовности сборки. Казалось бы, все логично: разработка закончена - передаем задачу в QA.

На практике это превращалось в бесконечный круг согласований.

Начинаешь тестировать, а в требованиях обнаруживаются пробелы: - Что будет, если в числовое поле ввести буквы? 🐘 - Какой текст ошибки должен увидеть пользователь? - Куда перенаправить пользователя после сохранения? - Что делать, если обязательное поле осталось пустым?

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

Задача отправляется по кругу: аналитик → разработчик → тестирование → снова аналитик.

Время идет, сроки сдвигаются, а команда переделывает уже написанное.

Я решила изменить подход.

Не ждать готовую сборку, а подключаться к задаче раньше.

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

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

Спрашиваю: «Ребята, а так и задумано?»

И иногда выясняется, что нет. 😅

Параллельно готовлю тест-кейсы. Если возникают вопросы, обсуждаем их с аналитиком и разработчиком, пока задача еще в работе.

В результате к моменту передачи сборки в QA у меня уже есть понимание логики, согласованные требования и подготовленные проверки.

Это не означает, что дефектов больше не будет. Но мы значительно сокращаем количество возвратов из-за вопросов, которые можно было закрыть заранее.

Что дает раннее подключение QA? 1. Проблемы в требованиях обнаруживаются до разработки, когда исправлять их проще. 2. Разработчик не тратит время на переделку функциональности из-за неучтенных сценариев. 3. Тестировщик не ждет уточнений после получения сборки, а может сразу приступать к проверкам. 4. Команда лучше понимает, что именно и с каким результатом должна реализовать.

Для меня QA - это не этап, который начинается после разработки. Это участник процесса создания продукта.

И нет, я не собираюсь мешать разработчику писать код. 😉 Просто предпочитаю задать десять вопросов до разработки, чем получить десять возвратов после нее.