База для QA
К списку уроков
Блок 4 · Тестовая документация — практика

Урок 13. Тест-кейсы

Подробное описание проверок

Темы урока

Структура тест-кейса (предусловия/шаги/ожидаемый результат/постусловия), позитивные/негативные, traceability к требованиям

Видео урока

Пройти тест по уроку

Конспект урока

Урок 13. Тест-кейсы: подробное описание проверок

Тест-кейс vs чек-лист

Тест-кейс — это не «нажал кнопку и посмотрел». Это воспроизводимый сценарий с точными данными, конкретными шагами и проверяемым ожидаемым результатом.

Чек-лист Тест-кейс
Отвечает на «Что проверить» — список зон «Как проверить» — пошаговый сценарий
Детализация Средняя: тезисы и пункты Высокая: предусловие + шаги + ОР
Когда подходит Быстрый проход, нестабильные требования Регресс, воспроизведение бага, онбординг
Когда писать тест-кейс Формальная приёмка, передача знаний в команде Любой сценарий, где важно повторить результат

Структура тест-кейса: 6 ключевых полей

ID + Название → Предусловие → Шаги → Ожидаемый результат → Постусловие → Приоритет
# Поле Назначение
1 ID и название Уникальный идентификатор и короткое описание сценария
2 Предусловие Состояние системы и данные перед первым шагом
3 Шаги Последовательность атомарных действий
4 Ожидаемый результат Что должно произойти после каждого шага или в конце
5 Постусловие Состояние системы после завершения (если нужно сбросить)
6 Приоритет и статус Зависят от TMS и договорённостей в команде

Предусловие: без него тест не воспроизводится

Предусловие описывает стартовое состояние, которое должно быть выполнено до первого шага.

Плохо: «Открыт сайт»
Хорошо: «Авторизован пользователь test@qa.ru, корзина пустая, открыт каталог Пиццаеда»

Размытое предусловие — главная причина, почему разработчик говорит «у меня работает», а тест «не воспроизводится». Конкретное предусловие снимает 90% споров.

Шаги: пиши так, чтобы выполнил кто угодно

Правила атомарности:

  • Один шаг — одно действие
  • Плохо: «Открыть сайт и нажать кнопку» — два разных шага
  • Хорошо: «Шаг 1: Открыть каталог Пиццаеда» / «Шаг 2: Нажать "В корзину" у пиццы "Маргарита"»

Правила конкретности:

  • Указывай точные данные: «Ввести промокод QA60», не «ввести какой-нибудь промокод»
  • Указывай конкретный элемент: «Нажать кнопку "Оформить заказ" в нижней части корзины»

Ожидаемый результат: конкретика вместо «всё работает»

Пример
Плохо «Товар добавляется в корзину»
Хорошо «Счётчик в хедере изменился с 0 на 1; в корзине появился товар "Маргарита" 1 шт. 599₽, итого 599₽ + доставка 199₽»

Ожидаемый результат можно указывать для каждого шага, а не только для последнего — особенно если шаг критичен.

Позитивные и негативные тест-кейсы

Позитивные — happy path и расширенные сценарии:

  • Happy path: самый типичный сценарий («добавить пиццу и оформить заказ успешно»)
  • Расширенные: граничные значения в пределах допустимого («добавить 99 единиц товара»)
  • Выполняются при каждом регрессе — основа покрытия

Негативные — где прячутся реальные баги:

  • Проверяют поведение при неверных данных или выходе за пределы допустимого
  • Примеры: ввести 0 товаров, применить промокод с пробелом, отправить пустую форму
  • 70% реальных багов находят именно в негативных сценариях

Traceability: зачем связывать тест с требованием

Traceability — это связь «этот тест-кейс проверяет вот это требование / задачу / user story».

Зачем нужно:

  • Можно ответить: «У нас 200 тест-кейсов — все ли требования покрыты?»
  • При изменении требования сразу понятно, какие тест-кейсы нужно обновить

Как реализуется:

  • В TMS: поле «Linked Issue» или «Requirements»
  • В таблице: столбец «ID требования»

Демо: тест-кейсы для корзины «Пиццаеда»

Позитивный: «Добавить товар в корзину»

Предусловие: авторизован пользователь test@qa.ru, корзина пустая, открыт каталог Пиццаеда

Шаг 1: Нажать «В корзину» у пиццы «Маргарита»
ОР: Счётчик корзины в хедере = 1

Шаг 2: Открыть корзину
ОР: Товар «Маргарита» 1 шт. 599₽, итого 599₽ + доставка 199₽

Негативный: «Промокод на пустую корзину»

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

Шаг 1: Ввести QA60 в поле «Промокод» и нажать «Применить»
ОР: Скидка не применяется, появляется сообщение об ошибке (или промокод не активируется)

Шаг 2: Проверить итоговую сумму
ОР: Сумма не изменилась, промокод не активирован

Типичные ошибки при написании тест-кейсов

«Шаги без данных»

  • Плохо: «Ввести email»
  • Хорошо: «Ввести test@qa.ru в поле Email»

«Ожидаемый результат — не результат»

  • Плохо: «Нажать ОК»
  • Хорошо: «Открылась страница подтверждения заказа с номером»

«Мега-тест-кейс»

  • 50 шагов в одном кейсе — значит, проверяет несколько разных сценариев
  • Правило: разбей на 3–5 атомарных кейсов — так проще локализовать упавший шаг

Уровень детализации

Детализацию выбирают под задачу:

Ситуация Уровень
Формальный регресс, передача знаний Полный (предусловие + шаги + ОР на каждый шаг)
Опытная команда, устоявшийся продукт Можно сокращать шаги, но предусловие и ОР — всегда
Воспроизведение сложного бага Максимальная детализация

Правило проверки: тест-кейс написан правильно, если коллега выполнит его без дополнительных вопросов.

Как писать названия тест-кейсов: формула «Где? Что? Как?»

Чёткое название — ключ к быстрому пониманию и навигации в TMS.

Часть Вопрос Примеры
Где? Модуль, страница, функция «Корзина», «Личный кабинет», «Форма оформления»
Что? Что проверяем, какая операция «Добавление товара», «Применение промокода», «Изменение количества»
Как? Специфика сценария, данные «с валидными данными», «с невалидным промокодом», «при пустой корзине»

Формула итогового названия:

[Где] — [Что] — [Как]

Примеры:

  • Корзина — Добавление товара — позитивный сценарий
  • Корзина — Применение промокода — с невалидным кодом
  • Форма заказа — Отправка — с пустым полем телефона
  • Личный кабинет — Изменение email — на уже существующий

Название должно читаться как самостоятельное утверждение: взглянув на него в списке, сразу понятно что и где проверяется — без открытия самого кейса.

Чек-лист качества тест-кейса

Перед тем как сохранить тест-кейс, пройдись по этим критериям:

Критерий Что проверить
Ясность Простой язык без двусмысленностей — любой член команды выполнит без дополнительных вопросов
Конкретность Точные шаги («Нажать "Войти"» вместо «Авторизоваться»), точные данные и ожидаемые сообщения
Атомарность Один тест-кейс — одна проверка; не объединять несколько сценариев в один кейс
Независимость Тест выполняется отдельно, без жёсткой зависимости от других тест-кейсов
Повторяемость При одинаковых условиях результат всегда одинаков
Полнота Покрывает соответствующее требование
Эффективность Баланс между детализацией и простотой — не слишком длинный и не слишком общий
Актуальность Регулярно обновляется при изменениях в ПО

Ключевые выводы урока

  1. Тест-кейс = воспроизводимый сценарий: точное предусловие + конкретные шаги + проверяемый ожидаемый результат
  2. Негативные тест-кейсы — не опционально: 70% реальных багов живут именно там
  3. Шаги — атомарные: одно действие = один шаг; конкретные данные вместо «что-нибудь»
  4. Traceability связывает тест с требованием — позволяет контролировать покрытие
  5. Тест-кейс написан правильно, если выполнить его может кто угодно без подсказок

Домашнее задание

Написать 10 тест-кейсов для корзины «Пиццаеда» (aiqa.ru/base/shop):

  • Минимум 5 позитивных и 5 негативных сценариев
  • Каждый кейс: ID, название, предусловие, шаги с ожидаемыми результатами, постусловие (если нужно)

Сдавать в чат марафона.