Приведи пример плохого тест кейса

Пример плохого тест-кейса и его анализ

Контекст приложения

Рассмотрим функцию регистрации пользователя в веб-приложении. Поля формы: имя пользователя, email, пароль (с подтверждением), чекбокс «Согласен с условиями».

Плохой тест-кейс

ID: TC-REG-001
Название: Проверить регистрацию.
Предусловия: Зайти на сайт.
Шаги:

1. Заполнить поля.
2. Нажать кнопку «Зарегистрироваться».
   Ожидаемый результат: Пользователь зарегистрирован.
   Постусловия: Выйти из системы.

---

Критический разбор недостатков

Этот тест-кейс — классический пример антипаттерна в тест-дизайне. Он плох по нескольким ключевым аспектам.

1. Неспецифичное и расплывчатое название

«Проверить регистрацию» не дает никакой информации о цели проверки. Хорошее название должно отражать конкретный сценарий, например: «Успешная регистрация с валидными данными» или «Регистрация с уже существующим email».

2. Отсутствие конкретных тестовых данных

Шаг «Заполнить поля» абсолютно неконкретен. Какой email использовать? Какой пароль? Валидный или нет? Это делает тест невоспроизводимым. Хороший тест-кейс должен явно указывать данные или ссылаться на набор тестовых данных.

# Пример хорошего шага с данными
Когда я заполняю поле "Имя пользователя" значением "test_user_123"
И я заполняю поле "Email" значением "new.user@example.com"
И я заполняю поле "Пароль" значением "SecurePass123!"
И я заполняю поле "Подтверждение пароля" значением "SecurePass123!"
И я устанавливаю чекбокс "Согласен с условиями" в состояние "отмечен"

3. Слишком общий и неполный ожидаемый результат

«Пользователь зарегистрирован» — это нетестируемое утверждение. QA-инженер не может проверить это напрямую. Ожидаемый результат должен быть наблюдаемым и верифицируемым в интерфейсе.

• После успешной регистрации:

    *   Должно отобразиться сообщение «Регистрация завершена успешно!».
    *   Произошел автоматический вход в систему, и в хедере отображается имя пользователя.
    *   Произошел редирект на страницу личного кабинета.

• Должна быть создана запись в базе данных с указанным email.

    *   *Примечание: Это уже может быть отдельным тестом API/интеграции.*

4. Проверяет сразу всё (тест-слияние)

Скорее всего, автор хотел проверить положительный сценарий. Но из формулировки неясно, проверяет ли он работу кнопки, валидацию полей, создание учетной записи или процесс логина после регистрации. Один тест-кейс должен проверять одну конкретную функциональность или правило.

5. Игнорирование негативных сценариев и граничных значений

Наиболее ценные баги часто находят в негативных сценариях. Данный тест-кейс их полностью игнорирует. Хорошая тест-сумка (test suite) для регистрации должна включать:

• Попытка регистрации с пустым обязательным полем.
• Несовпадение пароля и подтверждения.
• Email в неверном формате.
• Пароль, не соответствующий политике безопасности (менее 8 символов, без цифр).
• Регистрация с email, который уже существует в системе.
• Отправка формы без принятия условий использования.

6. Неясные предусловия и постусловия

«Зайти на сайт» — какой именно URL? Главная страница или страница регистрации? Постусловие «Выйти из системы» может быть невыполнимо, если регистрация по какой-то причине не прошла. Предусловия должны гарантировать чистое состояние системы (например, «Учетная запись с email new.user@example.com отсутствует в базе данных»).

---

Как должен выглядеть хороший тест-кейс (исправленный пример)

ID: TC-REG-001-POS
Название: Успешная регистрация нового пользователя с валидными данными.
Приоритет: High
Предусловия:

1. Открыта страница регистрации (/signup).
2. В базе данных отсутствует пользователь с email test.auto@example.com.

Шаги:

Ожидаемые результаты:

1. Система отображает тост-сообщение: «Регистрация прошла успешно! Добро пожаловать, autotest_user!».
2. Происходит автоматический редирект на страницу личного кабинета (/profile).
3. В хедере страницы отображается приветствие: «Привет, autotest_user».
4. (Для интеграционного теста) Запись с email test.auto@example.com присутствует в таблице users БД.

Постусловие: Удалить тестового пользователя (test.auto@example.com) через API администратора или прямое обращение к БД для обеспечения чистоты следующих тестов.

Заключение: Плохой тест-кейс — это потраченное впустую время на этапах выполнения, анализа результатов и сопровождения. Он ведет к ложным срабатываниям (false positives), пропуску дефектов и неэффективной коммуникации в команде. Качество тест-кейсов напрямую влияет на покрытие (coverage) и эффективность всего процесса QA. Хороший тест-кейс должен быть конкретным, атомарным, воспроизводимым, четким и поддерживаемым.