Урок 10 — Regression Testing

Название: Regression Testing — убеждаемся, что старое не сломалось
Описание: Разбираем, что такое регрессионное тестирование, зачем оно нужно, как его планировать, когда запускать и как автоматизировать с помощью Playwright.
Почему это важно для QA: Регрессионное тестирование — это один из самых важных видов тестирования в долгосрочных проектах. Каждое изменение кода потенциально ломает то, что работало раньше. Regression Testing — ваша страховка от этого.

1. Что такое регрессия

Регрессия (regression) — это когда ранее работавшая функция перестаёт работать после внесения изменений в систему.

Аналогия

Представь здание. Строители укрепляют одну стену, но при этом нечаянно повреждают несущую балку в другом конце здания. Визуально всё выглядит нормально, но через неделю потолок просел. Это регрессия.

В программировании: разработчик исправляет баг в модуле оплаты — и нечаянно ломает фильтрацию товаров в каталоге. Функции не связаны напрямую, но код — это взаимосвязанная система.

2. Что такое Regression Testing

Regression Testing — это повторное тестирование ранее проверенной функциональности с целью убедиться, что новые изменения не нарушили уже работающий функционал.

Ключевые свойства

3. Когда проводить Regression Testing

Regression Testing нужен после:

• Исправления бага (bug fix)
• Добавления новой функции
• Рефакторинга кода
• Обновления зависимостей (библиотек, фреймворков)
• Изменения конфигурации или окружения
• Слияния веток (merge)

Правило

Если что-то изменилось в коде — нужна регрессия. Даже «безобидное» изменение может сломать что-то неожиданное.

4. Виды Regression Testing

4.1 Full Regression

Полное тестирование всего приложения. Запускается перед крупным релизом.

Плюсы: максимальное покрытие
Минусы: долго, ресурсоёмко

4.2 Partial Regression (Selective)

Тестируется только часть системы, связанная с изменениями.

Пример: изменили модуль корзины → тестируем корзину + оплата + профиль заказов
Не тестируем: авторизация, каталог, поиск (не затронуты)

Плюсы: быстрее, экономит ресурсы
Минусы: можно пропустить неожиданные связи

4.3 Progressive Regression

Добавляем новые тест-кейсы для нового функционала к существующему регрессионному набору.

4.4 Re-test All

Полный прогон всех тест-кейсов без исключений. Используется редко — только для критических систем.

5. Стратегия отбора тестов для регрессии

Не всегда есть время тестировать всё. Вот как отбирать тесты:

6. Пример: Regression Suite для интернет-магазина

REGRESSION SUITE: Интернет-магазин v2.1.0
────────────────────────────────────────────
БЛОК 1: Авторизация (приоритет: высокий)
  ✓ Вход с корректными данными
  ✓ Вход с неверным паролем → ошибка
  ✓ Выход из аккаунта
  ✓ Сессия сохраняется при обновлении страницы

БЛОК 2: Каталог (приоритет: средний)
  ✓ Список товаров загружается
  ✓ Фильтрация по категории работает
  ✓ Сортировка по цене работает
  ✓ Поиск возвращает корректные результаты

БЛОК 3: Корзина (приоритет: высокий — был затронут)
  ✓ Добавление товара в корзину
  ✓ Изменение количества товара
  ✓ Удаление товара из корзины
  ✓ Промокод применяется корректно
  ✓ Итоговая сумма считается правильно

БЛОК 4: Оформление заказа (приоритет: высокий)
  ✓ Переход к оформлению из корзины
  ✓ Заполнение адреса доставки
  ✓ Выбор способа оплаты
  ✓ Подтверждение заказа
  ✓ Email-подтверждение отправлено

Итого: 20 тестов
Время (авто): ~8 минут

7. Автоматизация регрессии в Playwright

Регрессионные тесты — идеальный кандидат для автоматизации. Они повторяются при каждом релизе.

Пример структуры

tests/
  regression/
    auth/
      login.spec.ts
      logout.spec.ts
      session.spec.ts
    catalog/
      filters.spec.ts
      search.spec.ts
      sorting.spec.ts
    cart/
      add-product.spec.ts
      promo-code.spec.ts
      price-calculation.spec.ts
    checkout/
      order-flow.spec.ts
      payment.spec.ts

Пример регрессионного теста: promo-code.spec.ts

import { test, expect } from "@playwright/test";
import { CartPage } from "../../pages/CartPage";

const PROMO_CODES = {
  valid: "SAVE20",
  invalid: "FAKECODE",
  expired: "EXPIRED2023",
} as const;

test.describe("Регрессия: применение промокода", () => {
  test("валидный промокод применяет скидку 20%", async ({ page }) => {
    const cartPage = new CartPage(page);

    await cartPage.goto();
    await cartPage.addProduct("Товар тест", 1);
    await cartPage.applyPromoCode(PROMO_CODES.valid);

    const discountedPrice = await cartPage.getTotalPrice();
    expect(discountedPrice, "Скидка должна быть 20%").toBe(800);
  });

  test("невалидный промокод показывает ошибку", async ({ page }) => {
    const cartPage = new CartPage(page);

    await cartPage.goto();
    await cartPage.addProduct("Товар тест", 1);
    await cartPage.applyPromoCode(PROMO_CODES.invalid);

    await expect(
      cartPage.promoErrorMessage,
      "Должна появиться ошибка о невалидном промокоде"
    ).toBeVisible();
  });

  test("истёкший промокод не применяется", async ({ page }) => {
    const cartPage = new CartPage(page);

    await cartPage.goto();
    await cartPage.addProduct("Товар тест", 1);
    await cartPage.applyPromoCode(PROMO_CODES.expired);

    await expect(
      cartPage.promoErrorMessage,
      "Должно появиться сообщение об истёкшем промокоде"
    ).toContainText("истёк");
  });
});

Конфигурация в playwright.config.ts

export default defineConfig({
  projects: [
    {
      name: "regression",
      testMatch: "**/regression/**/*.spec.ts",
      retries: 1,
      use: {
        baseURL: process.env.BASE_URL,
        screenshot: "only-on-failure",
        video: "retain-on-failure",
      },
    },
  ],
});

8. Regression Testing в CI/CD

# Пример GitHub Actions workflow
name: Regression Tests

on:
  push:
    branches: [main, release/**]
  schedule:
    - cron: "0 2 * * *"   # каждую ночь в 2:00

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test tests/regression/
        env:
          BASE_URL: ${{ secrets.STAGING_URL }}
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: regression-report
          path: playwright-report/

9. Метрики регрессионного тестирования

Хорошие показатели

Pass Rate: > 95%
Execution Time: < 30 минут для полного набора
Coverage: > 80% критических функций

10. Частые ошибки

❌ Регрессию проводят только перед крупным релизом
→ Её нужно проводить после каждого значимого изменения. Чем раньше найден баг — тем дешевле его исправить.

❌ Регрессионный набор не обновляется
→ Если добавлена новая функция — добавь тесты для неё в регрессию. Иначе через год регрессия покрывает 30% продукта.

❌ Все тесты в регрессии равнозначны
→ Расставляй приоритеты. Критические пути тестируй всегда, второстепенные — по возможности.

Итог

REGRESSION TESTING
├── Цель: убедиться, что изменения не сломали старое
├── Когда: после любых изменений в коде
├── Что включать: критические функции + изменённые модули
├── Главная угроза: регрессионный набор устаревает
├── Лучшая практика: автоматизация + CI/CD
└── Метрика успеха: Pass Rate > 95%