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

Чек-лист против тест-кейса

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

  • Регистрация с валидными данными
  • Занятый e-mail
  • Пустые поля
  • Слишком короткий пароль
  • Неверный формат e-mail (без «собаки»)
  • Пробелы в начале и конце полей
  • Очень длинное имя

Разница с тест-кейсом: кейс говорит как проверять (пошагово) и что ожидать; чек-лист говорит только что проверить, а «как» тестировщик держит в голове.

Когда что выбирать:

  • Чек-лист — когда проверки простые и понятные, времени мало, а тестировщик опытный. Быстро составить, быстро пройти. Отлично подходит для разведочного тестирования и быстрых smoke-проверок.
  • Тест-кейс — когда проверка сложная, важен точный порядок, кейс будут проходить другие люди или он ляжет в регресс надолго. Дороже составить, но однозначен и повторяем.

На практике часто начинают с чек-листа (быстро накидать, что вообще проверить), а самые важные пункты потом разворачивают в полноценные кейсы.

Что такое тестовые данные

Тестовые данные — это конкретные значения, которые вы подставляете в проверки: логины, пароли, суммы, файлы, тексты. Кажется мелочью, но именно от данных зависит, найдёте вы баг или нет. Проверка «ввести имя» с данными «Анна» пройдёт всегда — а вот имя из 300 букв, имя с эмодзи или с апострофом (O'Brien) вполне может что-нибудь сломать.

Полезно всегда готовить данные трёх сортов:

  • Валидные — правильные, «счастливый путь»: обычное имя, корректный e-mail, нормальная сумма.
  • Невалидные — заведомо неправильные: пустое поле, буквы вместо цифр, e-mail без «собаки», отрицательная сумма.
  • Граничные — по краям допустимого: имя ровно в максимальную длину и на один символ длиннее, минимальная и максимальная сумма (см. граничные значения).

Коварные данные, о которых забывают

Отдельно стоит запомнить набор «неудобных» данных, которые регулярно ломают неопытный код:

  • Пусто и пробелы — пустое поле, только пробелы, пробелы по краям.
  • Очень длинный текст — тысяча символов там, где ждали десять.
  • Спецсимволы — кавычки, апострофы ('), угловые скобки (<>), знаки процента, эмодзи.
  • Разные языки и регистры — кириллица, иероглифы, ПРОПИСНЫЕ и строчные.
  • Числа-ловушки — ноль, отрицательное, очень большое, дробное там, где ждали целое.
  • Даты-ловушки — 29 февраля, вчера и завтра, дата в прошлом для «даты рождения» в будущем.

Держите этот список под рукой — он один приносит массу багов на самых обычных формах.

Где взять данные

Три обычных источника:

  • Придумать самому — для простых полей достаточно.
  • Взять из требований — там часто есть примеры и ограничения (максимальная длина, формат).
  • Сгенерировать — для массовых или реалистичных данных есть бесплатные генераторы (по запросу «test data generator»): случайные имена, адреса, номера карт для тестов.

Важное правило: никогда не используйте настоящие персональные данные реальных людей для тестов. Это и небезопасно, и часто незаконно. Для проверок берут выдуманные или обезличенные данные.

Где это применяется

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

Где спотыкаются начинающие:

  • Проверяют только «Анна» и «anna@example.com» — красивые валидные данные — и потому находят только очевидное. Баги в неудобных данных.
  • Забывают про спецсимволы, длину и пустоту — самый плодотворный набор данных.
  • Расписывают подробные кейсы там, где хватило бы чек-листа, и тратят время впустую.
  • Берут реальные данные людей для тестов — так делать нельзя.

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