Структура тест-кейса: как написать понятную пошаговую инструкцию для проверки функции

Почему это важно

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

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

В этом уроке вы узнаете, из каких частей состоит тест-кейс, что писать в каждой из них и как оформить готовый тест-кейс так, чтобы его мог использовать любой коллега — даже тот, кто видит программу впервые.

Теория

Что такое тест-кейс

Тест-кейс (от английского test case — «тестовый случай») — это документ, в котором записано:

• что именно проверяется,
• как это нужно проверить (шаги),
• что должно произойти в конце (ожидаемый результат).

💡 Аналогия. Тест-кейс похож на инструкцию по сборке мебели из IKEA: у вас есть список деталей, пронумерованные шаги и картинка того, что должно получиться. Если что-то пошло не так — вы сразу видите расхождение с картинкой.

Обязательные части тест-кейса

Стандартный тест-кейс состоит из семи элементов. Разберём каждый подробно.

1. Идентификатор (ID)

Идентификатор — это уникальный «номер паспорта» тест-кейса. Он нужен, чтобы легко ссылаться на него в других документах: например, в баг-репорте написать «ошибка воспроизводится в тест-кейсе TC-007».

Формат может быть любым — главное, чтобы не было двух одинаковых:

• TC-001 (TC = Test Case)
• LOGIN-003
• CART-012

2. Название

Название — краткое описание того, что именно проверяется. Пишется как ответ на вопрос: «Что мы тестируем?»

Хорошие примеры:

• «Успешный вход в систему с корректными данными»
• «Добавление товара в корзину»
• «Ошибка входа при неверном пароле»

Плохие примеры:

• «Тест №1» — непонятно, что проверяется
• «Проверить всё» — слишком широко

📌 Правило: прочитав только название, любой человек должен понять, о чём тест-кейс.

3. Предусловия

Предусловия — это условия, которые должны быть выполнены до начала проверки. Если их не соблюсти, проверка не будет иметь смысла.

💡 Аналогия. Перед тем как проверить, заводится ли машина, нужно убедиться, что в баке есть бензин. Это и есть предусловие.

Примеры предусловий:

• «Пользователь зарегистрирован в системе»
• «Открыт браузер Google Chrome»
• «Корзина покупок пуста»
• «Нет подключения к интернету» (для тестов офлайн-режима)

Если предусловий нет — так и пишут: «Предусловия отсутствуют».

4. Тестовые данные

Тестовые данные — конкретные значения, которые используются при выполнении проверки. Вместо размытого «введите логин» нужно написать «введите логин [email protected]».

Примеры:

• Логин: [email protected]
• Пароль: Qwerty123!
• Сумма: 999,99 ₽

📌 Зачем это нужно? Если не указать конкретные данные, два тестировщика могут ввести разные значения и получить разные результаты. Точность — залог воспроизводимости.

5. Шаги выполнения

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

Требования к шагам:

• Начинать с глагола действия: «Открыть», «Нажать», «Ввести», «Выбрать»
• Один шаг = одно действие
• Написаны так чётко, что их сможет выполнить человек, впервые видящий программу

Плохо написанный шаг:

«Войти в систему»

Этот шаг слишком размытый. Что нужно сделать для входа? Где ввести данные?

Хорошо написанные шаги:

1. Открыть браузер и перейти на страницу https://example.com/login
2. В поле «Email» ввести [email protected]
3. В поле «Пароль» ввести Qwerty123!
4. Нажать кнопку «Войти»

6. Ожидаемый результат

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

💡 Аналогия. В рецепте: «Должен получиться пышный бисквит золотистого цвета». Если вместо этого у вас плоский блин — что-то пошло не так.

Ожидаемый результат должен быть конкретным и проверяемым:

Плохо:

«Пользователь входит в систему» — непонятно, как это выглядит на экране

Хорошо:

«Страница перенаправляет на личный кабинет. В шапке сайта отображается имя пользователя Иван Петров. Надпись "Войти" исчезает.»

7. Фактический результат и статус

Эти поля заполняются во время выполнения тест-кейса:

• Фактический результат — что реально произошло
• Статус — итог сравнения:
  • ✅ Pass (пройден) — фактический результат совпал с ожидаемым
  • ❌ Fail (провален) — есть расхождение, найдена ошибка
  • ⏭️ Skip (пропущен) — тест не запускался (например, функция ещё не готова)
  • 🚫 Blocked (заблокирован) — тест не удалось запустить из-за другой ошибки

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

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

Это важное разделение, которое стоит понять с самого начала.

Позитивный тест-кейс — проверяет, что программа правильно работает при корректных входных данных. Это сценарий «всё хорошо»: пользователь делает всё правильно.

Пример: Вход с корректным логином и паролем → ожидаем успешный вход.

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

Пример: Вход с неверным паролем → ожидаем сообщение «Неверный пароль», а не «Ошибка сервера 500».

📌 Опытные тестировщики знают: большинство ошибок программ прячется именно в негативных сценариях. Разработчики обычно хорошо пишут код для «счастливого пути», но забывают обработать нестандартные ситуации.

Как не надо писать тест-кейсы: типичные ошибки

Пример: готовый тест-кейс

Рассмотрим реальный пример тест-кейса для проверки формы входа на сайт интернет-магазина.

## TC-003: Успешный вход зарегистрированного пользователя

**Тип:** Позитивный  
**Приоритет:** Высокий  
**Автор:** Мария Иванова  
**Дата:** 2024-01-15  

---

### Предусловия
1. Пользователь зарегистрирован в системе с email `[email protected]` и паролем `TestPass1!`
2. Пользователь НЕ авторизован (выполнен выход из системы)
3. Открыт браузер Google Chrome (версия 120 или новее)

---

### Тестовые данные
- Email: `[email protected]`
- Пароль: `TestPass1!`

---

### Шаги выполнения

1. Открыть браузер и перейти по адресу `https://shop.example.ru`
2. В шапке страницы нажать кнопку «Войти»
3. Убедиться, что открылась страница авторизации с полями «Email» и «Пароль»
4. В поле «Email» ввести `[email protected]`
5. В поле «Пароль» ввести `TestPass1!`
6. Нажать кнопку «Войти в аккаунт»

---

### Ожидаемый результат

- Система перенаправляет пользователя на главную страницу
- В правом верхнем углу вместо кнопки «Войти» отображается имя пользователя
- Отображается уведомление «Добро пожаловать!»
- Никаких сообщений об ошибках нет

---

### Фактический результат
*(заполняется при выполнении)*

---

### Статус
- [ ] Pass  
- [ ] Fail  
- [ ] Skip  
- [ ] Blocked  

А вот негативный тест-кейс для той же формы — проверяем неверный пароль:

## TC-004: Попытка входа с неверным паролем

**Тип:** Негативный  
**Приоритет:** Высокий  

---

### Предусловия
1. Пользователь зарегистрирован с email `[email protected]`
2. Пользователь НЕ авторизован
3. Открыт браузер Google Chrome

---

### Тестовые данные
- Email: `[email protected]`
- Пароль: `НеверныйПароль999`

---

### Шаги выполнения

1. Перейти на страницу авторизации `https://shop.example.ru/login`
2. В поле «Email» ввести `[email protected]`
3. В поле «Пароль» ввести `НеверныйПароль999`
4. Нажать кнопку «Войти в аккаунт»

---

### Ожидаемый результат

- Пользователь остаётся на странице авторизации
- Под формой появляется сообщение об ошибке: «Неверный email или пароль»
- Поле пароля очищается
- Перехода в личный кабинет не происходит

---

### Статус
- [ ] Pass  
- [ ] Fail  
- [ ] Skip  
- [ ] Blocked  

Практика

Выполните следующие задания самостоятельно. Для каждого задания используйте структуру тест-кейса, изученную в уроке. Вы можете писать в любом текстовом редакторе — Markdown, Word, Google Docs или даже в тетради.

Упражнение 1: Найдите ошибки

Перед вами плохо написанный тест-кейс. Найдите минимум 4 ошибки и запишите, как их исправить.

Тест: Регистрация
Шаги:
1. Зайти на сайт
2. Нажать регистрацию
3. Заполнить всё и отправить
4. Войти

Результат: работает

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

Упражнение 2: Напишите тест-кейс с нуля

Представьте приложение «Калькулятор» на телефоне. Напишите полноценный позитивный тест-кейс для проверки операции сложения двух чисел.

Используйте все обязательные поля:

• ID, Название, Предусловия, Тестовые данные, Шаги, Ожидаемый результат

Совет: Подумайте, какие конкретные числа вы будете складывать. Не пишите «введите два числа» — укажите именно 7 и 5.

Упражнение 3: Позитивный и негативный сценарии

Представьте форму поиска товара в интернет-магазине. Напишите два тест-кейса:

1. Позитивный: пользователь вводит название существующего товара и находит его.
2. Негативный: пользователь вводит название несуществующего товара.

Подумайте: что должна показывать программа в каждом случае? Как должно выглядеть сообщение, если товар не найден?

Упражнение 4 (повышенный уровень): Мыслите шире

Возьмите любое приложение, которым пользуетесь каждый день (мессенджер, приложение банка, социальная сеть). Выберите одну функцию (например, «Отправить сообщение», «Перевести деньги», «Поставить лайк»).

Напишите для неё три тест-кейса:

1. Один позитивный (всё работает правильно)
2. Один негативный (ввод некорректных данных)
3. Один на граничное значение — например, отправить пустое сообщение или перевести 0 ₽

Что такое граничное значение? Это данные на краю допустимого диапазона. Программы часто ломаются именно «на границах»: при пустом вводе, при максимально длинном тексте, при нулевой сумме. Проверять такие случаи — хорошая привычка.

Ключевые выводы

• Тест-кейс — это пошаговая инструкция для проверки одной конкретной функции программы; он даёт одинаковый результат в руках любого тестировщика.
• Обязательные элементы тест-кейса: ID, название, предусловия, тестовые данные, шаги, ожидаемый результат, статус.
• Каждый шаг должен описывать одно конкретное действие и начинаться с глагола («Нажать», «Ввести», «Открыть»).
• Тестовые данные должны быть конкретными числами, текстами или значениями — никаких «введите корректные данные».
• Ожидаемый результат должен быть проверяемым: что именно появляется на экране, какое сообщение, что меняется.
• Позитивные тест-кейсы проверяют счастливый путь; негативные — поведение программы при ошибках пользователя.
• Большинство ошибок прячется в негативных и граничных сценариях — не пренебрегайте ими.
• Хорошо написанный тест-кейс экономит время: его можно передать коллеге или вернуться к нему через полгода — и всё будет понятно без дополнительных объяснений.