Lesson 25 of 26

Урок 25 — Test Case: как писать хорошие тест-кейсы

Название: Test Case — основа тестирования
Описание: Разбираем структуру тест-кейса, компоненты, виды, как правильно писать тест-кейсы на разных уровнях — от Junior до Middle. Примеры для ручного и автоматизированного тестирования.
Почему это важно для QA: Тест-кейс — это главный артефакт тестировщика. Плохо написанный тест-кейс теряет баги и занимает время. Хороший — воспроизводим, понятен любому, экономит часы.

1. Что такое Test Case

Test Case (тест-кейс) — это набор условий, шагов и ожидаемых результатов, по которым можно проверить конкретную функциональность системы.

Аналогия

Рецепт приготовления блюда:

Условия = ингредиенты и инвентарь
Шаги = последовательность действий
Ожидаемый результат = как должно выглядеть готовое блюдо

Если рецепт написан чётко — любой повар приготовит одинаковый результат. Так же и с тест-кейсом: любой QA-инженер должен получить одинаковый результат при его выполнении.

2. Структура тест-кейса

Обязательные поля

Поле	Описание	Пример
ID	Уникальный идентификатор	TC-001, AUTH-005
Название	Краткое описание что тестируется	«Вход с корректными данными»
Предусловия	Что должно быть сделано до начала	Пользователь зарегистрирован
Шаги	Последовательность действий	1. Открыть /login...
Ожидаемый результат	Что должно произойти	Редирект на /dashboard
Приоритет	Критичность	High / Medium / Low
Статус	Результат выполнения	Pass / Fail / Blocked / Skip

Дополнительные поля

Поле	Описание
Тестовые данные	Конкретные значения для теста
Окружение	Браузер, ОС, версия
Автор	Кто написал тест-кейс
Дата	Когда создан / обновлён
Связанные требования	REQ-42, USER-STORY-15
Фактический результат	Что реально произошло (заполняется при Fail)

3. Пример тест-кейса (ручное тестирование)

Хороший тест-кейс: авторизация

ID:              TC-AUTH-001
Название:        Успешный вход с корректными учётными данными
Модуль:          Авторизация
Приоритет:       High
Тип:             Functional, Positive

Предусловия:
  1. Пользователь зарегистрирован в системе (email: testuser@test.com)
  2. Открыт браузер Chrome последней версии
  3. Пользователь не авторизован (нет активной сессии)

Тестовые данные:
  Email:    testuser@test.com
  Пароль:  TestPass123!

Шаги:
  1. Открыть https://staging.shop.com/login
  2. В поле "Email" ввести: testuser@test.com
  3. В поле "Пароль" ввести: TestPass123!
  4. Нажать кнопку "Войти"

Ожидаемый результат:
  - URL изменяется на https://staging.shop.com/dashboard
  - На странице отображается приветствие: "Добро пожаловать, Test User"
  - В шапке сайта отображается аватар/имя пользователя
  - В DevTools: Cookie с именем "sessionId" создан с флагом HttpOnly

Статус: [ ] Pass  [ ] Fail  [ ] Blocked  [ ] Skip
Фактический результат: (заполняется при Fail)
Примечания:

4. Пример тест-кейса: негативный сценарий

ID:              TC-AUTH-003
Название:        Блокировка после 5 неудачных попыток входа
Модуль:          Авторизация
Приоритет:       High
Тип:             Functional, Negative, Security

Предусловия:
  1. Пользователь testuser@test.com существует
  2. Аккаунт не заблокирован

Тестовые данные:
  Email:    testuser@test.com
  Пароль:  WrongPass123 (намеренно неверный)

Шаги:
  1. Открыть /login
  2. Ввести email: testuser@test.com, пароль: WrongPass123
  3. Нажать "Войти" → зафиксировать сообщение об ошибке
  4. Повторить шаги 2–3 ещё 4 раза (итого 5 попыток)
  5. На 5-й попытке зафиксировать сообщение

Ожидаемый результат:
  После 5-й неудачной попытки:
  - Отображается сообщение: "Аккаунт заблокирован на 15 минут. Попробуйте позже."
  - Кнопка "Войти" становится неактивной (disabled)
  - Попытка войти с правильным паролем → тоже блокировка (аккаунт заблокирован)
  - Через 15 минут — аккаунт разблокируется автоматически

Статус: [ ] Pass  [ ] Fail  [ ] Blocked  [ ] Skip

5. Виды тест-кейсов

По ожидаемому результату

Вид	Описание	Пример
Позитивный	Корректные данные, happy path	Вход с правильным паролем
Негативный	Некорректные данные, edge cases	Вход с неверным паролем
Граничный	Граничные значения (BVA)	Пароль ровно 8 символов

По уровню детализации

Уровень	Описание	Когда использовать
High-level	Общее описание без деталей	Ранние стадии проекта
Low-level	Детальные шаги с конкретными данными	Регрессия, документация

6. Ошибки при написании тест-кейсов

❌ Плохой тест-кейс

ID: TC-001
Название: Проверить форму входа
Шаги:
  1. Войти в систему

Ожидаемый результат:
  Всё работает

Проблемы:

«Войти в систему» — что именно делать? Какие данные?
«Всё работает» — как понять, что работает?
Нет предусловий
Нет тестовых данных
Непонятно, что считать успехом

✅ Хороший тест-кейс

ID: TC-AUTH-001
Название: Успешный вход с корректными email и паролем
Предусловия: Пользователь user@test.com зарегистрирован, не авторизован
Тестовые данные: email = user@test.com, password = ValidPass123
Шаги:
  1. Перейти на /login
  2. Ввести в поле Email: user@test.com
  3. Ввести в поле Пароль: ValidPass123
  4. Нажать кнопку "Войти"
Ожидаемый результат:
  - URL: /dashboard
  - Отображается "Добро пожаловать, Test User"
  - Cookie sessionId создан

7. Правила написания хороших тест-кейсов

7.1 Одна проверка = один тест-кейс

❌ Плохо: TC-001 "Проверить авторизацию" — 20 шагов, проверяет вход, выход, смену пароля
✅ Хорошо: TC-001 "Вход с правильным паролем"
           TC-002 "Выход из аккаунта"
           TC-003 "Смена пароля"

7.2 Конкретные значения, не обобщения

❌ «Ввести корректный email»
✅ «Ввести email: testuser@example.com»

❌ «Нажать кнопку»
✅ «Нажать кнопку "Оформить заказ" (синяя кнопка в правом нижнем углу страницы)»

7.3 Конкретный ожидаемый результат

❌ «Вход выполнен успешно»
✅ «URL меняется на /dashboard, отображается "Добро пожаловать, Иван"»

❌ «Появляется ошибка»
✅ «Появляется сообщение: "Неверный логин или пароль" красным цветом под кнопкой»

7.4 Независимость тест-кейсов

❌ Плохо: TC-002 зависит от TC-001 (работает только если TC-001 прошёл)
✅ Хорошо: каждый тест-кейс начинается с чистого состояния

8. Test Case vs Test Scenario vs Test Suite

TEST SUITE (набор тестов)
└── TEST SCENARIO (сценарий) — «Авторизация пользователя»
    ├── TEST CASE (тест-кейс) — «Вход с корректными данными»
    ├── TEST CASE — «Вход с неверным паролем»
    ├── TEST CASE — «Вход с пустым email»
    └── TEST CASE — «Блокировка после 5 неудачных попыток»

Термин	Что это
Test Suite	Набор тест-кейсов для модуля / функции
Test Scenario	Пользовательский сценарий (high-level)
Test Case	Детальные шаги проверки одного аспекта
Test Step	Один шаг внутри тест-кейса

9. Test Case в автоматизации (Playwright)

Каждый тест-кейс становится одним test() блоком:

typescripttypescript

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

// TC-AUTH-001: Успешный вход
test("TC-AUTH-001: вход с корректными учётными данными", async ({ page }) => {
  // Предусловие: пользователь не авторизован (свежий браузер)
  const loginPage = new LoginPage(page);

  // Шаги
  await test.step("открыть страницу входа", async () => {
    await loginPage.goto();
  });

  await test.step("ввести корректные данные и нажать войти", async () => {
    await loginPage.login("testuser@test.com", "TestPass123!");
  });

  // Ожидаемый результат
  await test.step("убедиться в успешном входе", async () => {
    await expect(page, "URL должен измениться на /dashboard").toHaveURL("/dashboard");
    await expect(
      page.getByText("Добро пожаловать"),
      "Должно отображаться приветствие"
    ).toBeVisible();
  });
});

// TC-AUTH-003: Блокировка после 5 неудачных попыток
test("TC-AUTH-003: блокировка после 5 неудачных попыток", async ({ page }) => {
  const loginPage = new LoginPage(page);
  await loginPage.goto();

  // Шаги: 5 неудачных попыток
  for (let attempt = 1; attempt <= 5; attempt++) {
    await test.step(`неудачная попытка ${attempt}`, async () => {
      await loginPage.login("testuser@test.com", "WrongPass123");
    });
  }

  // Ожидаемый результат после 5-й попытки
  await expect(
    loginPage.lockoutMessage,
    "Должно появиться сообщение о блокировке"
  ).toContainText("Аккаунт заблокирован");
  await expect(
    loginPage.submitButton,
    "Кнопка входа должна быть неактивна"
  ).toBeDisabled();
});

10. Приоритизация тест-кейсов

Приоритет	Когда выполнять	Примеры
Critical	Всегда, в первую очередь	Авторизация, оплата
High	Smoke + Regression	Основные бизнес-функции
Medium	Full Regression	Дополнительные сценарии
Low	Если есть время	Косметические, редкие случаи

Итог

TEST CASE — это:
├── ID (уникальный идентификатор)
├── Название (что тестируем)
├── Предусловия (что должно быть готово)
├── Тестовые данные (конкретные значения)
├── Шаги (конкретная последовательность)
└── Ожидаемый результат (измеримый, конкретный)

Правила хорошего тест-кейса:
✓ Один тест — одна проверка
✓ Конкретные данные, не обобщения
✓ Измеримый ожидаемый результат
✓ Независим от других тестов
✓ Понятен любому члену команды