Manual Testing

БЛОК 5. Документация тестирования — 15. Тест-кейсы

📚 25 вопросовПройти тест →
Лекция

БЛОК 5. Документация тестирования — 15. Тест-кейсы

Manual Testing

БЛОК 5. Документация тестирования — 15. Тест-кейсы

🧭 Введение: зачем QA вообще пишет тест-кейсы

Многие джуны думают, что тест-кейсы нужны только «для отчёта». На практике это рабочий инструмент команды: он фиксирует, что именно и как проверять, чтобы не зависеть от памяти и настроения.
Без тест-кейсов один и тот же функционал два тестировщика проверяют по-разному. В итоге результаты несравнимы, а баги теряются.
Ещё одна критичная роль тест-кейсов — это основа регресса. Когда функционал меняется, команда должна быстро проверить, что старые функции не сломались, и именно тест-кейсы превращаются в стабильный регрессионный набор.
💡 Совет:
Пишите тест-кейс так, чтобы другой QA смог выполнить его без устных пояснений.
✅ Вывод:
Тест-кейс — это не бюрократия, а инструкция, которая делает тестирование воспроизводимым.

⚠️ Проблема -> решение

Проблема: «проверил на глаз» нельзя нормально повторить, передать другому человеку или привязать к требованиям.
Решение: оформлять проверки в формате тест-кейсов с явной структурой: предусловия, шаги, ожидаемый результат, данные.
🟢 Если совсем просто:
Тест-кейс = понятный сценарий проверки с ожидаемым итогом.
🎯 Как понять, что этап прошёл успешно:
Любой QA в команде выполняет ваш тест-кейс одинаково и получает сопоставимый результат.

🛠️ Чем помогает и как работает

Тест-кейсы превращают хаотичные проверки в управляемый процесс. Они помогают планировать регресс, делать retest после фиксов и показывать покрытие требований.
Как это работает:
  • Шаг 1: берём требование и критерии приёмки.
  • Шаг 2: выделяем пользовательский поток и условия старта.
  • Шаг 3: пишем шаги проверки без двусмысленностей.
  • Шаг 4: фиксируем ожидаемый результат на каждом критичном шаге или в конце.
  • Шаг 5: добавляем тестовые данные и приоритет.
  • Шаг 6: после прогона заносим фактический результат (pass/fail + комментарий).
✅ Вывод:
Тест-кейс связывает требование, действия QA и объективный результат проверки.

📚 Ключевые термины (простыми словами)

  • Test case (тест-кейс) — документированный сценарий проверки с шагами и ожидаемым результатом.
  • Preconditions (предусловия) — что должно быть подготовлено до старта теста.
  • Test steps (шаги теста) — последовательность конкретных действий.
  • Expected result (ожидаемый результат) — что должно получиться при корректной работе системы.
  • Actual result (фактический результат) — что реально получилось при прогоне.
  • Test data (тестовые данные) — входные значения, которые используем в тесте.
  • Priority (приоритет) — насколько важно выполнить этот тест в первую очередь.
  • Traceability (трассируемость) — связь тест-кейса с требованием/AC.

1. Структура тест-кейса — без чего кейс считается «дырявым»

Хороший тест-кейс должен отвечать на три вопроса: что подготовить, что сделать, какой результат ожидать. Если хотя бы один слой отсутствует, тест становится спорным.
🟢 Если совсем просто:
Кейс без ожидаемого результата — это инструкция без критерия успеха.
🎯 Как понять, что этап прошёл успешно:
В кейсе есть минимальный обязательный каркас, и ни один шаг не требует «додумать за автора».
Назначение:
Сделать проверку воспроизводимой для любого QA.
Простыми словами:
Один человек написал, другой открыл и выполнил без потери смысла.
Для новичка:
Если ты не можешь пройти кейс без вопросов автору, кейс написан слабо.
Аналогия:
Это как рецепт: список ингредиентов (предусловия), шаги приготовления и ожидаемый результат блюда.
Пример:
ID: TC-LOGIN-001Название: Успешный вход с валидными даннымиПредусловия:- Пользователь зарегистрирован- Аккаунт активен Шаги:1. Открыть страницу /login2. Ввести валидный email3. Ввести валидный пароль4. Нажать кнопку Login Ожидаемый результат:- Пользователь авторизован- Открыта страница кабинета

🧱 Минимальный шаблон тест-кейса

Этот шаблон можно использовать как базовый стандарт для junior QA.
IDTitleRequirement / ACPreconditionsTest dataStepsExpected resultPriority
🔎 Как это происходит на практике:
  • QA получает задачу на логин.
  • По AC выделяет happy-path и обязательные предусловия.
  • Пишет кейс и отдаёт коллеге на «слепой прогон».
  • Если коллега проходит без уточнений, кейс готов.
Характеристики:
  • ✅ Ясные предусловия
  • ✅ Нумерованные действия
  • ✅ Проверяемый ожидаемый результат
Когда использовать:
Для критичных пользовательских потоков и регресса.
✅ Вывод:
Структура тест-кейса важнее красивого оформления.

2. Хороший и плохой тест-кейс

Самая частая ошибка джуна: кейс выглядит «длинно и серьёзно», но не даёт однозначного ответа pass/fail. Качество кейса определяется не объёмом, а точностью.
🟢 Если совсем просто:
Хороший кейс = конкретные действия + конкретный ожидаемый итог.
🎯 Как понять, что этап прошёл успешно:
По кейсу нельзя получить два разных толкования результата.
Назначение:
Убрать размытые формулировки и споры на триаже.
Простыми словами:
Чем меньше слов «корректно», «правильно», «как обычно», тем лучше.
Для новичка:
Пиши так, чтобы результат можно было проверить глазами и логами.
Пример:
Плохо:"Проверить логин, всё должно работать" Хорошо:"После нажатия Login пользователь видит /dashboard и access-token в cookie"

🎯 Правило: один кейс — одна цель

Один тест-кейс должен проверять одну конкретную цель.
❌ Неправильно:
Проверить логин, смену пароля и выход в одном кейсе.
✅ Правильно:
TC1 — login
TC2 — logout
TC3 — change password

🧩 Правило: шаг = действие, expected = проверка

Шаги описывают, что делает QA, а expected описывает, что проверяем после действий.
❌ Неправильно:
  1. Проверить логин
✅ Правильно:
  1. Ввести email
  2. Ввести пароль
  3. Нажать Login
Expected:
  • Открыта /dashboard
  • Кнопка Logout видима
🔎 Как это происходит на практике:
  • QA пишет черновик кейса.
  • Ревьюер ищет двусмысленные слова.
  • Неясные фразы заменяются измеримыми критериями.
Характеристики:
  • ✅ Измеримые проверки
  • ✅ Нет «магических» слов
  • ✅ Понятный pass/fail критерий
Когда использовать:
Всегда, особенно в smoke/regression наборах.
✅ Вывод:
Плохой кейс выглядит коротким, но съедает больше времени на исполнении.

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

Оба формата нужны, но решают разные задачи. Новички часто используют чек-лист там, где нужна детализация тест-кейса, и теряют качество на сложной логике.
🟢 Если совсем просто:
Чек-лист = что проверить, тест-кейс = как именно проверить.
🎯 Как понять, что этап прошёл успешно:
Для сложных потоков используется тест-кейс, для быстрых smoke-проверок — чек-лист.
Назначение:
Выбрать правильный уровень детализации под задачу.
Простыми словами:
Не каждый пункт требует полного сценария, но критичные потоки требуют.
Для новичка:
Если в проверке есть много условий и веток, бери тест-кейс, а не короткий чек-бокс.
Сравнение:
КритерийТест-кейсЧек-лист
ДетализацияВысокая (шаги + expected)Низкая (пункты проверки)
Скорость подготовкиНижеВыше
Скорость прогонаНижеВыше
Подходит для сложной логикиДаОграниченно
Подходит для быстрых smokeЧасто избыточенДа
🔎 Как это происходит на практике:
  • Перед релизом команда делит проверки.
  • Critical потоки оформляют тест-кейсами.
  • Вспомогательные UI-проверки оставляют в чек-листе.
Характеристики:
  • ✅ Гибкость формата
  • ✅ Баланс скорости и глубины
Когда использовать:
Когда нужно оптимизировать объём документации без потери контроля качества.
✅ Вывод:
Выбор формата зависит от риска и сложности, а не от личных привычек.

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

В реальном релизе редко есть время прогнать всё. Поэтому тест-кейсы нужно ранжировать: что проверяем обязательно, что можно перенести.
🟢 Если совсем просто:
Сначала кейсы, которые защищают деньги, доступ и ключевые потоки.
🎯 Как понять, что этап прошёл успешно:
У кейсов есть приоритет, и run order совпадает с рисками.
Назначение:
Снизить шанс пропустить критичный дефект при ограниченном времени.
Простыми словами:
Не все кейсы одинаково важны для релиза.
Для новичка:
Если времени мало, сначала прогони P1/P2, а не случайный список сверху вниз.
Пример:
P1: Оплата валидной картойP1: Защита от двойного списанияP2: Восстановление пароляP3: Кастомизация аватара
🔎 Как это происходит на практике:
  • QA lead формирует релизный список кейсов.
  • P1/P2 идут в первую волну прогона.
  • P3/P4 проверяются по остаточному времени.
Характеристики:
  • ✅ Прозрачный run order
  • ✅ Управление риском релиза
Когда использовать:
Всегда перед релизом и в nightly regression.
✅ Вывод:
Приоритеты в тест-кейсах экономят время без потери контроля над критичными рисками.

5. Traceability: связь тест-кейсов с требованиями

Если тест-кейсы не связаны с требованиями, сложно понять покрытие: что проверено, что забыто, где пробел. На ретроспективе это приводит к вопросу «как баг прошёл в релиз».
🟢 Если совсем просто:
У каждого кейса должна быть ссылка на AC/requirement.
🎯 Как понять, что этап прошёл успешно:
По любому требованию можно быстро найти соответствующие тест-кейсы.
Назначение:
Сделать покрытие требований прозрачным и проверяемым.
Простыми словами:
Тест-кейс без связи с требованием — это «проверка в воздухе».
Для новичка:
Добавляй поле Requirement ID в каждый кейс, особенно в регрессе.
Пример:
TC-PAY-004Requirement: AC-CHECKOUT-7Title: Повторный submit не создаёт второй заказ
🔎 Как это происходит на практике:
  • В задаче есть AC.
  • QA создаёт кейсы и проставляет связку AC -> TC.
  • На ревью видно, какие AC не покрыты.
Характеристики:
  • ✅ Ясное покрытие
  • ✅ Быстрый gap-анализ
Когда использовать:
В задачах с явными требованиями и на релизах с повышенным риском.
✅ Вывод:
Traceability превращает набор кейсов в управляемую систему качества.

6. Когда тест-кейсы писать не обязательно

Тест-кейсы полезны не в любой ситуации. Если писать их «на всё подряд», документация быстро разрастается и теряет ценность.
🟢 Если совсем просто:
Не каждая проверка требует полного тест-кейса.
🎯 Как понять, что этап прошёл успешно:
Команда использует тест-кейсы там, где нужна воспроизводимость, а для быстрых проверок выбирает более лёгкий формат.
Когда часто НЕ пишут полноценные тест-кейсы:
  • быстрый exploratory прогон;
  • временная фича или короткий эксперимент;
  • spike/prototype;
  • мелкие UI-правки без сложной логики.
Что использовать вместо этого:
  • краткий чек-лист;
  • ad-hoc тестирование с заметками;
  • короткий smoke-план.
✅ Вывод:
Формат документации выбирается по риску и длительности жизни функционала.

📌 Must-know факты

  • Тест-кейс должен давать однозначный pass/fail.
  • В expected result нельзя писать общие формулировки «работает корректно».
  • Preconditions и test data обязательны для воспроизводимости.
  • Один кейс = одна понятная цель проверки.
  • Шаги кейса описывают действия, expected — проверяемый результат.
  • Для high-risk потоков лучше тест-кейс, чем короткий чек-лист.
  • В каждом кейсе полезно фиксировать ссылку на requirement/AC.

❗ Частые мифы

❌ Миф: Чем длиннее тест-кейс, тем он качественнее. ✅ Как правильно: Качество кейса определяется ясностью и проверяемостью, а не длиной. 📎 Почему это важно: Длинные, но размытые кейсы хуже коротких и точных.
❌ Миф: Expected result можно не писать, «и так понятно». ✅ Как правильно: Expected обязателен, иначе нет объективного критерия pass/fail. 📎 Почему это важно: Без expected появляются споры и ложные баги.
❌ Миф: Чек-лист всегда лучше, потому что быстрее. ✅ Как правильно: Чек-лист быстрее, но хуже для сложной логики и критичных потоков. 📎 Почему это важно: Экономия на детализации часто приводит к пропущенным дефектам.
❌ Миф: Если кейс один раз написан, его не нужно обновлять. ✅ Как правильно: Тест-кейсы должны жить вместе с продуктом и изменяться при обновлении требований. 📎 Почему это важно: Устаревшие кейсы создают ложную уверенность в покрытии.

💬 Часто спрашивают на собеседованиях

❓ Вопрос: Какие поля вы считаете обязательными в тест-кейсе? ✅ Ответ: Минимум: ID, название, предусловия, шаги, expected result, test data и приоритет.
❓ Вопрос: Чем тест-кейс отличается от чек-листа? ✅ Ответ: Тест-кейс детализирует шаги и ожидаемый результат, чек-лист фиксирует только список проверок.
❓ Вопрос: Как понять, что тест-кейс написан хорошо? ✅ Ответ: Другой QA проходит его без уточнений, а результат однозначно определяется как pass/fail.
❓ Вопрос: Что делать, если времени мало и кейсов много? ✅ Ответ: Проставить приоритеты по риску и в первую очередь прогонять P1/P2 кейсы ключевых потоков.
❓ Вопрос: Зачем связывать кейсы с требованиями? ✅ Ответ: Чтобы видеть покрытие AC, быстро находить пробелы и объяснять релизные риски.

🚨 Типичные ошибки

Ошибка 1: Размытый expected result

❌ Неправильно: "Система должна работать корректно".
✅ Правильно: "Пользователь видит страницу /dashboard и кнопку Logout".
Почему:
Размытый expected нельзя проверить объективно.

Ошибка 2: Нет предусловий

❌ Неправильно: Кейс начинается сразу с шагов, без описания начального состояния.
✅ Правильно: Перед шагами фиксируем: пользователь создан, почта подтверждена, аккаунт активен.
Почему:
Без предусловий кейс невоспроизводим.

Ошибка 3: Несколько целей в одном кейсе

❌ Неправильно: Один кейс одновременно проверяет логин, сброс пароля и профиль.
✅ Правильно: Разделить на отдельные кейсы по одной цели.
Почему:
Иначе сложно локализовать дефект и определить точный статус кейса.

Ошибка 4: Нет связи с AC

❌ Неправильно: Кейс есть, но к какому требованию относится — неизвестно.
✅ Правильно: Указываем Requirement ID/AC в карточке кейса.
Почему:
Без traceability непонятно реальное покрытие требований.

Ошибка 5: Кейс не обновляют после изменения фичи

❌ Неправильно: Функционал изменился, кейс остался старым.
✅ Правильно: При каждом изменении требований обновлять соответствующие кейсы.
Почему:
Устаревшая документация создаёт ложное качество.

✅ Best Practices

  • Пишите кейс в активных и конкретных формулировках.
  • Один кейс — одна проверяемая цель.
  • Используйте шаблон, одинаковый для всей команды.
  • Проставляйте приоритет и requirement link сразу при создании.
  • Делайте peer-review тест-кейсов перед релизом.
  • Регулярно чистите устаревшие и дублирующие кейсы.

🏁 Заключение

Тест-кейсы — это база дисциплины в ручном тестировании.
Они делают результат проверки повторяемым, понятным и защищённым от «человеческого фактора».
Для junior QA сильный навык написания тест-кейсов напрямую влияет на качество баг-репортов, скорость регресса и доверие команды к вашим проверкам.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 5. Документация тестирования — 15. Тест-кейсы»

Пройти тест →