Как написать тест-кейс: пример, структура и типовые ошибки

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

Эта статья — о том, как писать кейсы, по которым может пройти кто угодно и результат которых не требует толкования. Мы разберём структуру по полям, покажем пример с шагами, сравним кейс с чек-листом и сценарием и перечислим ошибки, которые встречаем чаще всего при ревью чужих библиотек и импорте из других систем. Примеры взяты из пакетов Каталога QA Деск — они написаны по тем же правилам.

Определения

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

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

Тестовый сценарий — сквозная последовательность действий пользователя через несколько функций: «зарегистрироваться, положить товар в корзину, оплатить, получить письмо». Сценарий обычно раскладывается на несколько кейсов, либо оформляется как один длинный кейс, если функции проверяются только вместе.

Тест-план — набор кейсов, отобранных для конкретного прогона: релиз, обновление, конфигурация среды. О планах — отдельная статья.

Граница между кейсом и чек-листом проходит по вопросу «кто будет прогонять». Если всегда автор — достаточно чек-листа. Если коллега, подрядчик, новый сотрудник или вы сами через полгода — нужен кейс.

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

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

Название

Название читают чаще, чем сам кейс: в дереве библиотеки, в списке плана, в отчёте прогона. Оно должно отвечать на вопрос «что проверяем» без открытия кейса. «Проверка формы» — не название. «Форма заказа не отправляется с пустым телефоном» — название: понятно, что за форма, какое условие и какой результат ожидается.

Правило формулировки: объект + условие + ожидание, без слова «проверка» в начале — оно ничего не добавляет, а в списке из ста кейсов все начинаются одинаково.

Предусловия

Здесь описывается всё, что должно быть до первого шага: учётная запись и её права, тестовые данные, состояние системы, окружение. Предусловия — не шаги: «войти под администратором» — это шаг, «пользователь с ролью администратора существует» — предусловие.

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

Шаги

Каждый шаг — три части: действие, данные (если есть) и ожидаемый результат. Действие — одно на шаг: «нажать», «ввести», «открыть». Данные — конкретные: не «ввести e-mail», а user@example.com. Ожидаемый результат — то, что можно наблюдать: текст сообщения, состояние кнопки, запись в базе, письмо в ящике.

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

Приоритет и теги

Приоритет отвечает на вопрос «если времени мало, прогонять ли этот кейс». Критичный — без этой функции продуктом нельзя пользоваться; высокий — основной сценарий модуля; средний — вариант основного сценария; низкий — редкий случай или косметика. По приоритету из большой библиотеки собирается короткий смоук.

Теги — второе измерение отбора: по платформе, по релизу, по типу проверки. Тегов не должно быть много: если у кейса восемь тегов, ни по одному из них его никто не найдёт.

Пример тест-кейса

За основу взят кейс «Сброс пароля по ссылке из письма» из пакета «Регистрация и авторизация веб-приложения». В пакете он записан в четыре шага — для опытного тестировщика этого достаточно. Здесь он развёрнут до восьми, чтобы показать каждое поле в работе.

Название: Сброс пароля по ссылке из письма

Папка: Восстановление пароля · Приоритет: критичный · Теги: авторизация, регресс

Предусловия: зарегистрирован пользователь user@example.com с подтверждённой почтой и известным паролем; у тестировщика есть доступ к этому почтовому ящику; пользователь не авторизован.

Обратите внимание на шаги 6 и 8: они проверяют не то, что функция работает, а то, что она не работает там, где не должна. Старый пароль не подходит, ссылка одноразовая. Кейсы, в которых есть только «счастливый путь», находят вдвое меньше дефектов, чем кейсы с проверкой границ.

Типовые ошибки

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

Сколько кейсов нужно и какими они должны быть

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

Объём кейса — от 3 до 12 шагов. Меньше трёх — это, скорее, пункт чек-листа; больше двенадцати — два кейса или сценарий. Время прогона одного кейса вручную — от одной до десяти минут; если дольше, стоит посмотреть, нельзя ли часть подготовки вынести в предусловия или тестовые данные.

Чек-лист хорош там, где прогоняет автор и цена ошибки невелика. Кейс — там, где прогоняют другие, где результат нужно доказать и где по упавшему шагу заводится дефект. Большинство библиотек живут в обоих форматах: смоук — кейсами с критичным приоритетом, редкие проверки — чек-листом в описании функции.

Чек-лист: перед сохранением кейса

• Название отвечает на вопрос «что проверяем» без открытия кейса
• Предусловия описывают всё, что нужно до первого шага: учётка, данные, состояние
• В каждом шаге одно действие
• Данные конкретные, не «валидный e-mail»
• На каждом шаге, где система отвечает, есть наблюдаемый ожидаемый результат
• Есть хотя бы один шаг на границу: пустое поле, повтор, недостаток прав
• Кейс не зависит от других кейсов
• От 3 до 12 шагов; иначе — разбить или укрупнить
• Приоритет выставлен осознанно, тегов не больше трёх
• Кейс прогнан автором один раз до статуса «актуален»

Как это устроено в QA Деск

Библиотека тест-кейсов в QA Деск построена вокруг тех же полей: дерево папок, предусловия, шаги с действием, данными и ожидаемым результатом, приоритет, теги. Кейс имеет статус — черновик, актуален, архив — и версии: каждая правка сохраняется, а прогон ссылается на ту версию, которая была на момент старта, поэтому история прогонов не переписывается задним числом. Дефект заводится из упавшего шага и связывается с кейсом автоматически.

Если библиотека уже есть в таблице или в другой системе, её не нужно перебивать руками: импорт из CSV с построчным отчётом об ошибках и перенос из Test IT (XLSX/CSV) описаны в документации. А если библиотеки нет — в Каталоге восемь готовых пакетов для Битрикс24, 1С, интернет-магазина и веб-авторизации, написанных по правилам из этой статьи: их удобно взять как образец и переписать под свой продукт.