Кто добавляет тест-кейсы по новым фичам в регрессионное тестирование
Что проверяют
Понимаете ли вы, как регрессионный набор живёт и растёт и кто за это отвечает. Интервьюер ждёт, что вы назовёте конкретный момент в процессе, а не скажете «ну, QA». Следом обычно спрашивают, как вы не даёте регрессу разрастись до недели ручного прогона.
Как отвечать
Короткий ответ: чаще всего тест-кейсы добавляет QA, который тестировал фичу, и это прописано в Definition of Done задачи. Дальше покажите процесс:
- когда: не после релиза, а при закрытии задачи. Фича проверена, кейсы написаны, часть из них отмечена для регресса;
- что попадает в регресс: не все кейсы подряд, а основной пользовательский сценарий, места с высоким риском, интеграции и кейсы по найденным багам. Проверки редких полей и вёрстки обычно остаются в наборе самой фичи;
- где хранится: TestRail, Qase, Allure TestOps, Zephyr в Jira. Кейсы помечаются тегами или сьютами (smoke, регресс, кандидат в автоматизацию) и приоритетом;
- кто проверяет: QA-лид или коллега смотрит новые кейсы на дубли и понятность;
- автоматизация: кейс с меткой «автоматизировать» уходит в бэклог автотестов, после этого ручная копия удаляется или помечается как покрытая;
- чистка: при изменении или удалении фичи устаревшие кейсы правят или архивируют, иначе регресс копит мусор.
Опирайтесь на свой проект: сколько кейсов было в регрессе, сколько времени занимал прогон, какую долю покрывали автотесты. Цифры называйте реальные.
Если процесса не было, скажите об этом и объясните, как бы вы его ввели: пункт в DoD, тег в системе тест-менеджмента, ревью набора раз в спринт.
Где спотыкаются
Отвечают «все новые кейсы добавляем в регресс». Через год прогон занимает неделю, и его начинают пропускать.
Не упоминают актуализацию. Кейсы на удалённую функциональность падают на каждом прогоне и подрывают доверие к регрессу.
Считают, что за регресс отвечает только автоматизатор. Он автоматизирует то, что отобрали, а решение, что критично, принимает тот, кто знает фичу.