Урок 11 — Retesting

Название: Retesting — повторная проверка исправленного бага
Описание: Разбираем, что такое retesting, чем он отличается от regression testing, как правильно его проводить и документировать.
Почему это важно для QA: Retesting — это финальный шаг в жизненном цикле каждого бага. Без него невозможно официально закрыть дефект. Понимание разницы между retesting и regression — обязательный навык для любого QA-инженера.

1. Что такое Retesting

Retesting (повторное тестирование) — это проверка того, что конкретный баг был исправлен. Тестировщик берёт те же шаги воспроизведения, которые привели к дефекту, и выполняет их заново — убеждаясь, что проблема больше не воспроизводится.

Ключевое определение

Retesting = выполнение тех же самых тест-кейсов, которые ранее провалились, для проверки того, что дефект устранён.

2. Жизненный цикл бага и место Retesting

Нашли баг
    ↓
Написали баг-репорт (статус: New / Open)
    ↓
Разработчик исправил (статус: Fixed / In Review)
    ↓
QA проводит RETESTING
    ↓
    ├── Баг воспроизводится → статус: Reopened → возврат разработчику
    └── Баг НЕ воспроизводится → статус: Closed / Verified

3. Retesting vs Regression Testing

Это очень частый вопрос на собеседованиях. Запомни разницу:

Простая формула

RETESTING  = «Баг #1234 исправлен? Проверю шаги воспроизведения.»
REGRESSION = «После исправления бага #1234 всё ли остальное работает?»

4. Как правильно проводить Retesting

Шаг 1: Изучи оригинальный баг-репорт

Перед тестированием нужно знать:

• Точные шаги воспроизведения
• Фактический результат (что было сломано)
• Ожидаемый результат (что должно быть)
• Окружение (браузер, ОС, версия приложения)
• Тестовые данные, на которых баг воспроизводился

Шаг 2: Воспроизведи исходные условия

Пример: Баг был найден на пользователе с ролью "Admin" в Chrome 120
→ Retesting нужно делать с тем же типом пользователя и браузером

Шаг 3: Выполни шаги воспроизведения

Выполни точно такие же шаги, как в оригинальном баг-репорте. Не упрощай, не пропускай шаги.

Шаг 4: Зафиксируй результат

• Баг не воспроизводится → закрываем баг (Closed / Verified)
• Баг всё ещё воспроизводится → возвращаем на доработку (Reopened)
• Баг воспроизводится иначе → создаём новый баг-репорт + возвращаем старый

Шаг 5: Обнови статус в баг-трекере

Смени статус и добавь комментарий с результатами retesting.

5. Пример: Retesting реального бага

Оригинальный баг-репорт:

ID: BUG-2041
Заголовок: Кнопка "Сохранить профиль" не работает при наличии спецсимволов в имени
Приоритет: High
Статус: Fixed

Шаги воспроизведения:
1. Войти в аккаунт (testuser@test.com / Test1234)
2. Перейти в "Настройки профиля"
3. В поле "Имя" ввести: John <script>alert(1)</script>
4. Нажать "Сохранить"

Фактический результат: страница зависает, изменения не сохраняются
Ожидаемый результат: должна появиться ошибка валидации "Имя содержит недопустимые символы"

Окружение: Chrome 124, Windows 11, Staging v2.1.3

Действия при Retesting:

1. Зайти на Staging v2.1.4 (новая сборка с фиксом)
2. Открыть Chrome 124, войти под testuser@test.com / Test1234
3. Перейти в Настройки профиля
4. Ввести: John <script>alert(1)</script>
5. Нажать "Сохранить"

Результат retesting:
✅ Появилось сообщение "Имя содержит недопустимые символы"
✅ Страница не зависает
✅ Изменения не сохранились (корректное поведение)

→ Статус: CLOSED (Verified)

6. Дополнительные проверки при Retesting

Помимо основного сценария, стоит проверить граничные случаи того же бага:

Оригинальный баг: спецсимволы в поле "Имя" ломают форму

Дополнительные проверки при retesting:
✓ Спецсимволы в поле "Фамилия" — тоже исправлено?
✓ HTML-теги в поле "О себе" — тоже исправлено?
✓ SQL-инъекция в поле "Имя" — что происходит?
✓ Эмодзи в поле "Имя" — принимаются корректно?

Эти проверки — уже на грани Sanity Testing, но они логичны в контексте конкретного фикса.

7. Retesting в автоматизации

Если тест был автоматизирован и провалился из-за бага, после фикса:

// Тест, который ранее провалился (помечен как @bug BUG-2041)
test("должен показывать ошибку при вводе спецсимволов в имя @bug-2041", async ({
  page,
}) => {
  const profilePage = new ProfilePage(page);

  await test.step("перейти в настройки профиля", async () => {
    await profilePage.goto();
  });

  await test.step("ввести имя со спецсимволами", async () => {
    await profilePage.fillName('John <script>alert(1)</script>');
    await profilePage.clickSave();
  });

  await test.step("убедиться в валидационной ошибке", async () => {
    await expect(
      profilePage.validationError,
      "Должно появиться сообщение об ошибке"
    ).toContainText("недопустимые символы");
  });
});

После retesting убираем метку skip (если тест был временно отключён) и добавляем его в регрессионный набор.

8. Ошибки при Retesting

❌ Retesting проводится в другом окружении
→ Если баг воспроизводился в Firefox, делай retesting в Firefox, а не в Chrome.

❌ Тест-кейсы не те
→ Используй точно те же шаги, что в баг-репорте. Не упрощай.

❌ Закрывают баг без retesting
→ «Разработчик сказал, что починил» — недостаточно. QA должен лично проверить.

❌ Путают retesting и regression
→ После retesting обязательно провести regression для смежного функционала.

❌ Не документируют результат retesting
→ Всегда оставляй комментарий в баг-трекере с датой, версией и результатом.

9. Статусы бага в баг-трекере

Итог

RETESTING
├── Цель: подтвердить, что конкретный баг исправлен
├── Когда: после получения сборки с фиксом
├── Как: те же шаги воспроизведения, то же окружение
├── Результат 1: баг не воспроизводится → CLOSED
├── Результат 2: баг воспроизводится → REOPENED
└── После: провести Regression Testing для смежного функционала