Как выстраивать процессы тестирования с нуля?

Что проверяют

Есть ли у вас опыт или хотя бы внятный план, как навести порядок там, где тестирования нет. Интервьюеру важно, начнёте ли вы с понимания продукта и рисков или сразу с шаблонов документов. Следом спрашивают, что вы сделаете в первый месяц и как поймёте, что стало лучше.

Как отвечать

Стройте ответ как последовательность шагов на своём примере:

• аудит: какой продукт, как часто релизы, откуда приходят баги, что уже проверяют разработчики. Пара разговоров с командой даёт больше, чем неделя чтения требований;
• баг-трекер и правила: единый процесс заведения дефекта, статусы, критичность и приоритет, кто и когда закрывает. Инструмент обычно уже есть, Jira или YouTrack;
• минимум документации: сначала чек-листы по ключевым сценариям и smoke-набор перед релизом, подробные тест-кейсы только там, где цена ошибки высока. Хранить в TestRail, Qase, Test IT или хотя бы в вики;
• окружения и данные: отдельный стенд, понятный способ получить тестовые данные, правило, какая сборка где стоит;
• встраивание в поток: критерии готовности задачи, тестирование внутри спринта, регресс перед релизом;
• автоматизация: когда ручной регресс стабилен и повторяется, начинать с API и smoke-сценариев в CI, а не с хрупких UI-тестов;
• метрики: доля багов, найденных в проде, длительность регресса, время от релиза до обнаружения дефекта.

Если вы строили процесс сами, назовите свои цифры: размер команды, за сколько недель запустили, что изменилось. Если опыта не было, так и скажите и расскажите план первых 30, 60 и 90 дней: это убедительнее выдуманной истории.

Где спотыкаются

Начинают с того, что напишут тест-кейсы на всё приложение. Через месяц их никто не поддерживает, а продукт уже изменился.

Строят процесс в одиночку, не договорившись с разработкой и менеджером о критериях готовности. Тогда тестирование остаётся фазой, которую сокращают перед дедлайном.

Автоматизируют раньше, чем стабилизировали ручную проверку, и получают набор падающих тестов, которым никто не верит.