Что такое повторное тестирование?

Что такое повторное тестирование?

Повторное тестирование (Re-Testing) — это тип тестирования, при котором мы заново проверяем конкретный дефект (баг), который был ранее исправлен разработчиком, чтобы убедиться, что исправление действительно работает и не вызывает регрессии в данной функциональности. Это целенаправленная проверка одного и того же сценария с теми же самыми входными данными и условиями, которые привели к обнаружению оригинального бага.

Ключевые характеристики повторного тестирования:

• Целенаправленность: Проверяется исключительно исправленный дефект, а не вся функциональность вокруг.
• Детерминированность: Используются те же шаги, данные и окружение, что и при первоначальном обнаружении бага.
• Обязательность: Выполняется для всех исправленных дефектов перед закрытием соответствующего инцидента в трекере (Jira, Youtrack и т.д.).
• Ручное выполнение: Чаще всего это ручная операция, хотя при наличии автотеста, который падал из-за бага, его повторный прогон также можно считать частью процесса.

Отличие от регрессионного тестирования

Это критически важный момент, который часто вызывает путаницу.

• Повторное тестирование проверяет: "Исправлен ли конкретный баг #123?"
• Регрессионное тестирование проверяет: "Не сломалось ли что-то еще (смежные функции, вся система) из-за исправления бага #123?"

Аналогия: Представьте, что в машине не работал левый поворотник (баг). Механик его починил.

• Повторное тестирование — вы включаете именно левый поворотник и убеждаетесь, что он теперь мигает.
• Регрессионное тестирование — вы проверяете, не перестали ли из-за ремонта работать фары, стеклоочистители, магнитола и правый поворотник.

Процесс повторного тестирования в жизненном цикле дефекта

1. Обнаружение: QA-инженер находит дефект, документирует шаги для воспроизведения и создает баг-репорт.
2. Исправление: Разработчик исправляет код и помечает баг как "Исправлен" / "Ready for Test".
3. Повторное тестирование: QA берет этот конкретный баг-репорт:

    *   Подготавливает точное окружение (версия сборки, ОС, браузер).
    *   В точности повторяет шаги из описания.
    *   Проверяет, что дефект более не воспроизводится.

1. Верификация: Если баг исправлен — статус меняется на "Закрыт". Если нет — возвращается разработчику с комментарием ("Все еще воспроизводится" или "Появилась новая ошибка").

Пример на практике

Оригинальный баг: "При добавлении товара 'X' в корзину со страницы поиска, в корзину попадает товар 'Y'".

Шаги воспроизведения:

1. Перейти на сайт example.com.
2. В поиске ввести "Книга по тестированию".
3. В результатах нажать "В корзину" у товара "Совершенный код".
4. Перейти в корзину.
5. Ожидаемый результат: В корзине товар "Совершенный код".
6. Фактический результат: В корзине товар "Автоматизация тестирования".

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

# Это сценарий для повторного тестирования (не новый тест)
Сценарий: Повторная проверка бага #BUG-555 - некорректное добавление товара в корзину со страницы поиска
    Дано я нахожусь на главной странице example.com
    Когда я ввожу "Книга по тестированию" в строку поиска и нажимаю Enter
    И нажимаю кнопку "В корзину" у товара "Совершенный код" в результатах поиска
    И перехожу в корзину
    Тогда я вижу товар "Совершенный код" в списке товаров корзины
    # Ключевой момент: мы НЕ проверяем общую сумму, другие товары, оформление заказа.
    # Мы проверяем только исправление конкретного дефекта.

Важность и выводы

Повторное тестирование — это фундаментальная и обязательная практика контроля качества. Оно обеспечивает:

• Доверие к процессу исправления: Подтверждает, что работа разработчика завершена успешно.
• Чистоту трекера: Позволяет объективно закрывать задачи.
• Эффективность: Не требует написания новых тест-кейсов, использует уже существующую документацию дефекта.

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