Урок 08 — Sanity Testing

Название: Sanity Testing — быстрая проверка здравого смысла
Описание: Разбираем, что такое Sanity Testing, чем он отличается от Smoke Testing и Regression Testing, когда его проводить и как правильно применять на практике.
Почему это важно для QA: Sanity Testing помогает быстро определить, имеет ли смысл продолжать полное тестирование сборки после внесённых изменений. Это экономит время команды и позволяет быстро реагировать на критические проблемы.

1. Что такое Sanity Testing

Sanity Testing (тестирование здравомыслия) — это узкая, целенаправленная проверка конкретной функциональности или исправления бага после внесения изменений в систему.

Слово «sanity» означает «здравый смысл» или «разумность». Sanity Testing отвечает на вопрос: «Разумно ли продолжать полное тестирование этой сборки?»

Аналогия

Представь, что повар приготовил суп и внёс изменение в рецепт (добавил новую специю). Перед тем как подавать его гостям, ты делаешь один маленький глоток — проверяешь, не испортил ли он всё блюдо. Это и есть Sanity Testing.

Ты не пробуешь каждую ложку (это было бы Regression Testing). Ты просто проверяешь, что изменение не уничтожило суп.

2. Когда проводится Sanity Testing

Sanity Testing проводится:

• После исправления бага — убеждаемся, что фикс работает и ничего рядом не сломал
• После небольших изменений в функциональности
• После получения новой сборки от разработчиков
• Когда нет времени на полное регрессионное тестирование
• Когда нужно быстро убедиться, что критическая функция работает

3. Отличие от Smoke Testing

Это частый источник путаницы. Вот чёткая разница:

Простое правило

SMOKE    = широко, но неглубоко → «всё ли приложение живо?»
SANITY   = узко, но глубоко   → «этот конкретный фикс работает?»

4. Характеристики Sanity Testing

5. Пример: Sanity Testing после фикса бага

Ситуация: В интернет-магазине был баг — при применении промокода система не учитывала скидку и показывала полную цену.

Разработчик починил → выпустил новую сборку.

Что делает QA (Sanity Test):

1. Перейти в корзину
2. Добавить товар на 1000 ₽
3. Применить промокод SAVE20 (скидка 20%)
4. Проверить: итоговая сумма = 800 ₽  ← главная проверка
5. Оформить заказ → убедиться, что сумма 800 ₽ в подтверждении
6. Проверить смежные функции:
   - применение второго промокода (ожидаем: нельзя применить два)
   - удаление промокода (ожидаем: цена возвращается к 1000 ₽)

Это не полный Regression Test всего модуля оплаты — только целевая проверка исправленного функционала.

6. Пример из Playwright

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

// Sanity Test: проверка фикса промокода после деплоя
test("промокод SAVE20 применяет скидку 20%", async ({ page }) => {
  const cartPage = new CartPage(page);
  const checkoutPage = new CheckoutPage(page);

  await test.step("открыть корзину с товаром на 1000 ₽", async () => {
    await cartPage.goto();
    await cartPage.addProduct("iPhone Case", 1);
  });

  await test.step("применить промокод", async () => {
    await cartPage.applyPromoCode("SAVE20");
  });

  await test.step("проверить итоговую сумму со скидкой", async () => {
    const totalPrice = await cartPage.getTotalPrice();
    expect(totalPrice, "Скидка 20% должна применяться корректно").toBe(800);
  });

  await test.step("убедиться, что скидка сохраняется при оформлении", async () => {
    await cartPage.proceedToCheckout();
    const orderTotal = await checkoutPage.getOrderTotal();
    expect(orderTotal, "Итоговая сумма в заказе должна учитывать скидку").toBe(800);
  });
});

7. Когда Sanity Testing недостаточно

Sanity Testing не заменяет полноценное тестирование. Он лишь помогает быстро оценить ситуацию.

После успешного Sanity Test необходимо провести:

• Regression Testing — убедиться, что фикс не сломал другие функции
• Full Functional Testing — если изменения затрагивают большой модуль

Флаги для более глубокого тестирования

• Sanity Test прошёл, но команда не уверена в объёме изменений
• Изменение затронуло критическую бизнес-логику (оплата, авторизация)
• Разработчик предупредил об обширных изменениях в коде

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

❌ Путают Sanity с Smoke Testing
→ Запомни: Smoke = вся система поверхностно, Sanity = одна функция глубоко.

❌ Считают, что Sanity = регрессия после каждого фикса
→ Sanity — это быстрая проверка, а не полный прогон всех тестов.

❌ Не проводят Sanity, считая, что «разработчик всё проверил»
→ Разработчик тестирует свой код, но не тестирует его как пользователь.

Итог

SANITY TESTING
├── Цель: убедиться, что конкретный фикс/изменение работает
├── Когда: после получения новой сборки с исправлением
├── Объём: узкий, целенаправленный
├── Время: 15–60 минут
├── Не заменяет: Regression Testing и Full Testing
└── Ключевой вопрос: «Разумно ли продолжать полное тестирование?»