Как определить, что тест - кейс написан неправильно?

Критерии некорректного тест-кейса

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

1. Отсутствие ясности и конкретности

Тест-кейс нельзя интерпретировать двояко.

• Пример плохой формулировки: "Проверить работу формы обратной связи".
• Пример правильной формулировки: "Ввести валидный email в поле 'Email', текст в поле 'Сообщение' и нажать кнопку 'Отправить'. Ожидаемый результат: появление тоста 'Ваше сообщение отправлено'."

# ПЛОХО: Слишком абстрактно
Когда пользователь заполняет форму
Тогда она должна работать правильно

# ХОРОШО: Конкретные шаги и результат
Когда пользователь вводит "user@example.com" в поле "Email"
И вводит "Тестовое сообщение" в поле "Текст"
И нажимает кнопку "Отправить"
Тогда отображается уведомление "Сообщение успешно отправлено"

2. Проверка нескольких функций в одном тест-кейсе (Нарушение принципа атомарности)

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

• Пример антипаттерна: "Проверить регистрацию нового пользователя и затем его логин в систему". Это два отдельных сценария. Если падает регистрация, мы никогда не проверим логин.

3. Неоднозначный или отсутствующий ожидаемый результат

Каждый шаг, особенно шаг проверки (assertion), должен иметь четко определенный ожидаемый результат. Без него тест не является завершенным.

• Плохо: Шаги: "Нажать 'Сохранить'". Результат: "Данные сохраняются".
• Хорошо: Шаги: "Нажать 'Сохранить'". Результат: "В интерфейсе появляется зеленая плашка 'Изменения сохранены', а в базе данных в таблице users у записи с ID=5 обновляется поле name на 'Иван'".

4. Избыточная детализация или недостаток существенных данных

• Избыточность: Описание каждого клика на уровне "Навести курсор на поле, сделать клик левой кнопкой мыши". Это делает кейс громоздким.
• Недостаток данных: Использование абстрактных "тестовых данных" вместо конкретных примеров. Нужно явно указывать граничные значения, валидные и невалидные данные.

// ПЛОХО: Неясные данные
testFieldInput("data", "valid");

// ХОРОШО: Конкретные граничные значения
testFieldInput("username", "A"); // Нижняя граница (1 символ)
testFieldInput("username", "Abcdefghijklmnopqrst"); // Верхняя граница (20 символов)
testFieldInput("username", ""); // Негативный сценарий (пустая строка)

5. Зависимость от внешних факторов или других тест-кейсов

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

• Плохо: "Войти под пользователем, созданным в тест-кейсе TC-001".
• Хорошо: Использовать предусловия внутри кейса для создания необходимого состояния (через API или UI) и постусловия для очистки.

6. Отсутствие воспроизводимости

Если для выполнения кейса нужны специфические знания, доступы или ручные манипуляции с БД, которые не описаны, — он написан плохо. Все предусловия (версия О, данные, настройки) должны быть четко указаны.

7. Проверка тривиальных или нефункциональных аспектов

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

8. Несоответствие требованиям (Test Basis)

Это фундаментальная ошибка. Тест-кейс должен напрямую вытекать из пользовательской истории, требований (SRS) или спецификации. Если такого соответствия нет, кейс бесполезен.

Практический чек-лист для ревью тест-кейса

Проверяя кейс, задайте вопросы:

• Один ли сценарий он проверяет?
• Поймет ли новый член команды шаги и сможет их выполнить?
• Указан ли четкий ожидаемый результат для проверки?
• Является ли кейс независимым от других?
• Все ли необходимые тестовые данные явно указаны?
• Соответствует ли он актуальным требованиям?
• Можно ли его автоматизировать без переписывания? (Это хороший индикатор четкости).

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