Зачем это спрашивают
Вопрос выглядит простым, но интервьюер проверяет не определения, а умение выбирать. В реальной команде редко пишут подробные тест-кейсы на всё подряд: это долго, и такую документацию тяжело поддерживать. Но и одними чек-листами не обойтись, если проверку выполняют разные люди или результат нужно показать аудитору.
Сильный кандидат объясняет, чем форматы отличаются, и называет критерии, по которым выбирает между ними. Часто следом просят перечислить поля тест-кейса — к этому стоит быть готовыми.
Как построить сильный ответ
Начните с разницы в детализации, затем назовите поля тест-кейса и закончите критериями выбора.
Чек-лист
Список того, что нужно проверить, без подробных шагов. Каждая строка — одна проверяемая идея: «заказ из нескольких товаров отображается в истории профиля», «нельзя оформить заказ без адреса». Как именно проверять, исполнитель решает сам.
Плюсы: пишется быстро, легко обновляется, хорошо показывает покрытие на одной странице. Минусы: результат зависит от опыта исполнителя, двое людей проверят одну строку по-разному.
Тест-кейс
Описание одной проверки с шагами, данными и ожидаемым результатом. Его можно выполнить одинаково независимо от того, кто исполнитель.
| Поле | Зачем |
|---|---|
| ID | Ссылаться на кейс из прогона и баг-репорта |
| Название | Что проверяем, одной фразой |
| Предусловия | Состояние системы до шагов: роль, данные, настройки |
| Тестовые данные | Конкретные значения, а не «любой email» |
| Шаги | Последовательные действия |
| Ожидаемый результат | Проверяемый: у каждого шага или итоговый |
| Приоритет | Что прогонять первым, если времени мало |
| Связь с требованием | Покрытие и понимание, откуда взялось ожидание |
При прогоне к кейсу добавляют статус (пройден, не пройден, заблокирован, пропущен), сборку, стенд и ссылку на баг, если кейс упал.
Когда что выбирать
| Вопрос | Скорее чек-лист | Скорее тест-кейс |
|---|---|---|
| Кто проверяет? | Опытный тестировщик, знающий продукт | Новички, разные исполнители, аутсорс |
| Как часто? | Разово или функция часто меняется | Регулярно, в каждом регрессе |
| Цена ошибки? | Невысокая | Высокая: деньги, данные, юридические требования |
| Нужен ли аудит? | Нет | Да, нужно доказать, что и как проверено |
| Планируется автотест? | — | Подробный кейс — хорошая основа для автоматизации |
На практике форматы совмещают: начинают с чек-листа, а самые важные и часто повторяемые строки разворачивают в тест-кейсы. Строки чек-листа удобно получать техниками тест-дизайна — подробнее в статье про классы эквивалентности и граничные значения.
Пример ответа
Главная разница — в детализации. Чек-лист — это список проверяемых идей без шагов: пишется быстро, его легко обновлять, но результат зависит от опыта исполнителя. Тест-кейс описывает одну проверку целиком: ID, название, предусловия, конкретные тестовые данные, шаги, ожидаемый результат, приоритет и связь с требованием, а при прогоне — статус, сборку и ссылку на баг. Выбор зависит от того, кто проверяет, как часто и насколько дорога ошибка. Если функцию проверяю я сам и она часто меняется — хватит чек-листа. Если проверку повторяют в каждом регрессе разные люди, это платёжный сценарий или нужен аудит — пишу тест-кейсы. Часто совмещаю: начинаю с чек-листа и разворачиваю в кейсы самое важное.
Частые ошибки
- Говорить, что тест-кейс «всегда лучше». Подробная документация стоит времени на написание и поддержку.
- Перечислять поля тест-кейса без ожидаемого результата или предусловий.
- Писать в ожидаемом результате «всё работает корректно» — это нельзя проверить.
- Использовать абстрактные данные: «ввести любой адрес» вместо конкретного значения.
- Смешивать в одном кейсе несколько независимых проверок — при падении непонятно, какая из них не прошла.
- Не называть критериев выбора: кто, как часто, какая цена ошибки.
Пример на MarketCove
Возьмём историю заказов в профиле учебного магазина MarketCove. Чек-лист мог бы начинаться так:
- заказ, оформленный после входа, появляется в истории;
- в строке заказа видны номер, дата и статус;
- новый заказ отображается со статусом
PENDING; - после смены статуса сотрудником покупатель видит новый статус;
- гостевой заказ в профиле не появляется;
- после выхода и повторного входа история на месте.
Четвёртую строку стоит развернуть в тест-кейс: в ней участвуют две роли и смена состояния, и она повторяется в каждом регрессе:
- ID: PROFILE-ORD-04
- Название: статус, изменённый сотрудником, отображается в истории заказов покупателя
- Предусловия: есть аккаунт покупателя и учётная запись сотрудника с доступом к админке заказов; покупатель вошёл в аккаунт
- Данные: один конкретный товар из каталога; целевой статус, в который по правилам можно перевести заказ из
PENDING - Шаги: 1) оформить заказ покупателем; 2) запомнить номер со страницы успешного заказа; 3) открыть историю заказов в профиле; 4) под сотрудником найти заказ по номеру и сменить статус; 5) покупателем обновить историю заказов
- Ожидаемый результат: после шага 3 заказ в истории со статусом
PENDING; после шага 5 — с новым статусом, остальные поля заказа не изменились - Приоритет: высокий
Ситуация учебная: она показывает формат, а не поведение конкретной сборки магазина.
Задание для практики
Выберите в MarketCove поле «Адрес» в форме оформления заказа. Составьте чек-лист из 10–12 строк, используя классы эквивалентности и граничные значения для этого поля. Затем выберите две строки, которые, по вашему мнению, важнее всего для регресса, и разверните их в полноценные тест-кейсы по таблице полей выше.
Проверьте себя: можно ли выполнить ваш кейс, не задавая вопросов? Однозначен ли ожидаемый результат? После этого пройдите вопросы про тестовую документацию и, если хотите увидеть, как устроена практика целиком, откройте демо-урок.
