Как сократить время ретеста при появлении дефекта после длительного тестирования
Что проверяют
Различаете ли вы ретест и регресс и умеете ли выбирать, что перепроверить после исправления, вместо того чтобы прогонять всё заново. Следом обычно спрашивают, как вы решаете, что затронутая область проверена достаточно.
Как отвечать
Сначала разведите понятия. Ретест (confirmation testing) подтверждает, что конкретный дефект исправлен, по шагам из баг-репорта. Регресс проверяет, что исправление не сломало остальное. Время можно сократить на обоих.
- точный баг-репорт: шаги, тестовые данные, окружение, версия сборки. Ретест по хорошему репорту занимает минуты, по плохому уходят часы на повторное воспроизведение;
- анализ влияния: спросите разработчика, какие модули и эндпоинты задел фикс, посмотрите дифф в merge request. Регресс идёт по затронутой области, а не по всему набору;
- трассируемость: если кейсы в TestRail, Qase или Allure TestOps привязаны к требованиям и компонентам, нужная выборка делается фильтром;
- смоук и приоритеты: сначала короткий смоук по критичным сценариям, потом кейсы высокого приоритета, остальное по риску;
- автоматизация: регресс модуля запускается по тегам (
@Tagв JUnit 5, маркеры в pytest, группы в TestNG), параллельно, в CI на сборке с фиксом; - данные и окружение: сиды, SQL-скрипты, снапшоты БД, API-вызовы для предусловий. Часто дольше всего не сама проверка, а приведение системы в нужное состояние;
- пачка фиксов: если исправлений несколько, договоритесь брать их одной сборкой, чтобы не гонять регресс на каждый.
Закончите тем, что после ретеста на этот дефект появляется автотест, и он попадает в регресс.
Где спотыкаются
Путают ретест с регрессом или отвечают «перепрогоню весь регресс». Так вы показываете, что не умеете оценивать риск и не считаетесь со сроком релиза.
Сужают проверку, не спросив, что менял разработчик. Фикс в общем компоненте, например в валидации или авторизации, задевает десятки экранов, и узкий регресс пропустит поломку.
Отвечают одним словом «автоматизировать». Автотесты не помогут без стабильного окружения, готовых данных и понимания, что именно гонять: нестабильный набор на четыре часа ретест не сокращает.