Тест-кейс, чек-лист и тестовая документация

Документацию спрашивают, чтобы понять: вы работали в команде с процессом или тестировали «по наитию».

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

Вопрос 1: «Чем тест-кейс отличается от чек-листа и что выбрать?»

Что на самом деле проверяет интервьюер

Умеете ли вы соотносить формат документации с ситуацией. «Тест-кейсы лучше, потому что подробнее» — плохой ответ: подробность стоит времени, а его всегда мало.

Развёрнутый ответ

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

Как выглядит хороший тест-кейс

id: TC-142
title: Оплата заказа сохранённой картой при достаточном балансе
priority: high
preconditions:
  - Пользователь авторизован под test_user@example.com
  - В корзине один товар стоимостью 1990 руб.
  - К аккаунту привязана карта **** 4242
steps:
  - Открыть страницу корзины
  - Нажать «Перейти к оплате»
  - Выбрать сохранённую карту **** 4242
  - Нажать «Оплатить 1990 руб.»
expected:
  - Отображается экран «Заказ оплачен» с номером заказа
  - Статус заказа в личном кабинете — «Оплачен»
  - На почту приходит письмо с чеком

Признаки качества, которые стоит назвать вслух: атомарность (одна проверка — один кейс), однозначность (нет «проверить, что всё корректно»), независимость от других кейсов, конкретные тестовые данные, проверяемый ожидаемый результат.

Вопрос 2: «Что такое тест-план и что в нём должно быть?»

Что на самом деле проверяет интервьюер

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

Развёрнутый ответ

Тест-план отвечает на вопросы «что, как, кем, когда и при каких условиях мы тестируем». Опорный состав (в духе IEEE 829, но без фанатизма):

• Объект и объём: что тестируем и, отдельным пунктом, что не тестируем — этот раздел спасает от претензий после релиза;
• Подход и виды тестирования: уровни, техники, что автоматизируется;
• Критерии входа и выхода: когда начинаем и когда считаем тестирование законченным;
• Окружения и тестовые данные: стенды, версии, доступы;
• Роли и ответственность, расписание, оценка трудозатрат;
• Риски и меры: например, «внешний платёжный шлюз недоступен на стенде — используем sandbox».

Полезно уметь отделить тест-стратегию (документ уровня компании/продукта, живёт долго, описывает общий подход) от тест-плана (документ уровня проекта или релиза, конкретика и сроки). Ещё один частый вопрос — traceability matrix: матрица связей «требование → тест-кейсы», по которой видно, какие требования вообще не покрыты.

Типичные ошибки кандидатов

• Пишут неатомарные кейсы: «проверить регистрацию, авторизацию и восстановление пароля» — при падении непонятно, что именно сломалось.
• Ожидаемый результат формулируют как «всё работает корректно». Это не проверяемо и не годится ни для передачи коллеге, ни для автоматизации.
• Делают кейсы зависимыми: кейс 2 работает, только если перед ним прошёл кейс 1.
• Считают, что тест-план — это просто список тест-кейсов. Тест-план — про подход, риски, окружения и критерии.
• Не могут объяснить, зачем в тест-плане раздел «что не тестируем».

Как ответить кратко

Тест-кейс — это воспроизводимая инструкция с предусловиями, шагами и ожидаемым результатом; он дорог в написании и поддержке, зато его может выполнить любой человек и по нему легко автоматизировать. Чек-лист — короткий список «что проверить», дешёвый и гибкий, подходит опытной команде на своём продукте. На практике беру гибрид: чек-листы на большинство функциональности, детальные кейсы — на критичные сценарии вроде оплаты и прав доступа. Тест-план описывает не сами проверки, а подход: объём и то, что мы не тестируем, виды тестирования, критерии входа и выхода, окружения, роли, сроки и риски. Стратегия — документ уровня компании, план — уровня релиза.