Тест-кейс — это описание одной проверки: что сделать по шагам и какой результат ожидать. Он нужен, чтобы проверка была повторяемой: чтобы её мог пройти не только автор, но и любой другой человек, и через месяц, и получить тот же вывод.
Хороший тест-кейс похож на рецепт: настолько понятный, что новый человек в команде пройдёт его без вопросов. Разберём, из чего он состоит и что делает его хорошим.
Из чего состоит тест-кейс
Обычно в тест-кейсе есть такие части:
- Название — коротко и по делу, о чём проверка. Не «тест 1», а «Вход с верным логином и паролем».
- Предусловия — что должно быть готово ДО начала. Например: «пользователь зарегистрирован», «в корзине один товар». Это экономит шаги и убирает путаницу.
- Шаги — пронумерованные действия, по одному на пункт. «Открыть страницу входа», «Ввести логин», «Ввести пароль», «Нажать Войти».
- Ожидаемый результат — что должно произойти. «Открылась главная страница, вверху видно имя пользователя».
Иногда добавляют тестовые данные (конкретный логин/пароль), приоритет и ссылку на требование. Но ядро — это шаги + ожидаемый результат.
Пример: вход в систему
Название: Вход с верными данными
Предусловие: существует пользователь anna@example.com с паролем Test1234.
Шаги:
- Открыть страницу входа.
- Ввести в поле «E-mail» значение
anna@example.com. - Ввести в поле «Пароль» значение
Test1234. - Нажать кнопку «Войти».
Ожидаемый результат: пользователь попал на главную страницу, в правом верхнем углу отображается «Анна».
Обратите внимание: шаги конкретны (что вводим — прямо написано), а ожидаемый результат проверяемый (можно однозначно сказать, совпало или нет). «Всё работает» ожидаемым результатом быть не может — это непроверяемо.
Позитивные и негативные кейсы
На одну функцию всегда нужно несколько кейсов — минимум один позитивный и несколько негативных.
- Позитивный: «Вход с верными данными» (выше) — всё правильно, должно пустить.
- Негативные: «Вход с неверным паролем» (ожидаем ошибку «неверный логин или пароль»), «Вход с пустыми полями» (ожидаем, что кнопка неактивна или появляется подсказка), «Вход с незарегистрированным e-mail».
Правило новичка: на каждый позитивный кейс придумайте два-три негативных. Именно негативные ловят большинство багов, потому что «а что если ввести неправильно» разработчик часто не додумывает.
Что делает тест-кейс хорошим
Несколько признаков, по которым отличают хороший кейс от плохого:
- Однозначность. Разные люди поймут его одинаково и получат один результат. «Ввести корректный e-mail» — плохо (какой именно?). «Ввести
anna@example.com» — хорошо. - Проверяемый результат. Ожидание можно сравнить с фактом без споров.
- Независимость. Кейс не должен зависеть от того, прошли вы перед этим другой кейс или нет. Если зависит — вынесите нужное в предусловия.
- Одна проверка — один кейс. Не пытайтесь в одном кейсе проверить и вход, и корзину, и оплату. Иначе непонятно, что именно сломалось.
- Без лишних шагов. Всё, что можно убрать в предусловия, убирайте туда. Кейс должен быть о сути проверки, а не о десяти кликах разогрева.
Где это применяется
Тест-кейсы — это ваш основной рабочий инструмент и то, что остаётся после вас. Написанные однажды, они переиспользуются: при регрессе, при передаче задачи коллеге, при возврате к функции через полгода. Команда, у которой есть понятные кейсы, не зависит от памяти одного человека.
Где спотыкаются начинающие:
- Пишут расплывчато: «проверить оплату». Через неделю сам автор не вспомнит, что имелось в виду. Конкретика — в шагах и данных.
- Делают ожидаемый результат непроверяемым: «всё ок», «работает». Пишите, что конкретно должно появиться на экране.
- Пихают всё в один кейс. Одна проверка — один кейс; иначе не поймёте, что именно упало.
- Пишут только позитив. Без негативных кейсов вы проверяете лишь идеального пользователя, которого не существует.
Что учить дальше. Кейсов на большом продукте — сотни. Чтобы не утонуть, их организуют: тест-план и тест-сьюты. А чтобы придумывать кейсы умно, а не наугад, есть техники тест-дизайна.