Найти в Дзене

Как писать тест-кейсы чтобы не было стыдно

Если ты слышишь слово «тест-кейс», но пока думаешь, что это имя какого-то японского бойца из Tekken — расслабься, ты такой не один 😅 Сейчас разберёмся, как писать такие тест-кейсы, чтобы тебе самому не хотелось плакать, когда их читаешь. Ну и чтобы тимлид не кричал "Кто это писал?!" — хотя ты и так знаешь, кто 🙃 Просто:
Тест-кейс — это пошаговый сценарий, по которому ты проверяешь, что функция работает как надо. Типа чек-лист, только прокачанный. Например:
"Если я нажму ‘Войти’, введу почту и пароль — пущает ли меня внутрь?" Если пущает — хорошо. Если нет — пишем баг-репорт.
Если вообще зависло — зовём шамана. Или разработчика. Ха! Казалось бы, проще самому потыкать и всё. Но нет. Тест-кейсы нужны, чтобы: 📌 И чтобы на вопрос "А вы точно это проверяли?" не было мучительно больно... Вот классическая структура. Звучит серьёзно, но не бойся — это проще, чем звучит: Вот тебе инструкция с примерами. ❌ Плохо: Нажать на UI-компонент формы авторизации для инициирования обработки данных. ✅
Оглавление

Если ты слышишь слово «тест-кейс», но пока думаешь, что это имя какого-то японского бойца из Tekken — расслабься, ты такой не один 😅

Сейчас разберёмся, как писать такие тест-кейсы, чтобы тебе самому не хотелось плакать, когда их читаешь. Ну и чтобы тимлид не кричал "Кто это писал?!" — хотя ты и так знаешь, кто 🙃

Что такое тест-кейс?

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

Типа чек-лист, только прокачанный.

Например:
"Если я нажму ‘Войти’, введу почту и пароль — пущает ли меня внутрь?"

Если пущает — хорошо. Если нет — пишем баг-репорт.
Если вообще зависло — зовём шамана. Или разработчика.

Зачем вообще писать тест-кейсы?

Ха! Казалось бы, проще самому потыкать и всё. Но нет.

Тест-кейсы нужны, чтобы:

  • не забыть, что ты уже проверял (мозг — не Jira)
  • дать другому тестеру повторить твой путь
  • зафиксировать, что всё протестировано
  • потом запустить их снова (привет, регрессия)
  • убедиться, что ты не тестишь «на глазок»

📌 И чтобы на вопрос "А вы точно это проверяли?" не было мучительно больно...

Из чего состоит тест-кейс?

Вот классическая структура. Звучит серьёзно, но не бойся — это проще, чем звучит:

  1. ID — TC-001 и понеслась
  2. Название — кратко: “Проверка входа”
  3. Описание — зачем вообще этот кейс
  4. Предусловия — что должно быть до старта (например, “пользователь зарегистрирован”)
  5. Шаги — пошагово, как в IKEA-инструкции
  6. Ожидаемый результат — что должно произойти
  7. Статус — PASS/FAIL/Blocked
  8. Приоритет — насколько больно, если сломается
  9. Автор/дата — чтоб знать, кого винить/хвалить

Как писать, чтобы не стыдно было

Вот тебе инструкция с примерами.

✅ 1. Пиши понятно, как для бабушки

❌ Плохо:

Нажать на UI-компонент формы авторизации для инициирования обработки данных.

✅ Хорошо:

Нажать кнопку "Войти"

📢 Пиши так, чтобы понял даже джун.

✅ 2. Один кейс — один сценарий. Без комбо-ударов.

❌ Не надо:

Проверить логин с правильными и неправильными данными, а потом ещё посмотреть, что будет, если ничего не ввести.

✅ Надо:

  • TC-001: Успешный вход
  • TC-002: Неверный пароль
  • TC-003: Пустые поля

Тест-кейсы — не шаурма. Не надо заворачивать всё в один.

✅ 3. Конкретика, а не “там что-то как-то”

❌ Плохо:

Ввести корректные данные

✅ Отлично:

Ввести email: test@mail.com, пароль: 123456

Будь как Google — давай точные ответы.

✅ 4. Пиши шаги, как будто тебя проверяет самый вредный робот

Если шаги — как загадка из “Кто хочет стать миллионером”, тест-кейс пойдёт в урну.

Должно быть пошагово, чётко, как навигатор от Яндекса:

  1. Открой сайт
  2. Нажми “Вход”
  3. Введи логин
  4. Введи пароль
  5. Нажми “Войти”

✅ 5. Ожидаемый результат — твой индикатор победы

Без него непонятно: оно вообще сработало или нет?

❌ Не пиши:

Должно отработать корректно

✅ Пиши:

Пользователь переходит на главную страницу, отображается приветствие с именем

Если не знаешь, что ожидать — разработчик сам не в курсе, что ты тестишь.

✅ 6. Делай позитивные и негативные кейсы

  • Позитивные: вводим правильные данные, всё работает
  • Негативные: вводим чушь, смотрим, как всё ломается

✅ 7. Используй шаблон. Или не позорься в Google Docs

Если ты пишешь тест-кейсы в формате "написал в тетрадке, сфоткал, скинул в чат" — остановись.

Нормальные инструменты:

  • Google Таблица (на старте норм)
  • TestRail
  • qase.io
  • Zephyr (если в Jira)
  • PractiTest

Прокачай оформление — и ты уже на шаг ближе к мидлу

✅ 8. Обновляй тест-кейсы, как сторис в Инстаграме

Если продукт обновился — не оставляй тесты с шагом "нажать кнопку, которой больше нет".

✅ 9. Проставляй приоритет. Не всё важно одинаково

  • 🔴 High — если не работает, проект в *опе
  • 🟡 Medium — неприятно, но живём
  • 🟢 Low — пиксель съехал, никто не заметил (кроме дизайнера, конечно)

✅ 10. Пример нормального тест-кейса (а не то, что пишут на курсах за 3 дня)

ID: TC-007
Название: Невозможность входа с неверным паролем
Предусловия: Есть зареганный пользователь
Шаги:

  1. Перейти на https://example.com
  2. Нажать "Войти"
  3. Ввести email: user@example.com
  4. Ввести пароль: wrongpass123
  5. Нажать "Войти"

Ожидаемый результат:
Отображается сообщение "Неверный логин или пароль"

Приоритет: High
Автор: QA_Undercover
Дата: 27.07.2025

А если лень или не умею?

Тренируйся! Вот тебе идеи:

Тест-кейс на регистрацию в Instagram:

  • Что будет, если ввести email без "@"?
  • Что если пароль из 1 буквы?
  • Как работает кнопка "показать пароль"?

Тесты для корзины на Wildberries:

  • Добавить 3 товара — сколько покажет?
  • Удалить 1 — пересчёт корректный?
  • Что будет, если добавить 9999 товаров?

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

Финальный чекаут

🧠 Тест-кейсы — это не скучные таблички. Это твой боевой арсенал.
Пиши их:

  • понятно
  • чётко
  • с душой
  • и с уважением к тому, кто будет читать их после тебя (возможно, это будешь ты сам через месяц).