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

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

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

1. Смысловые и логические недостатки

• Отсутствие чёткой цели: Кейс не отвечает на вопрос "Что мы проверяем и зачем?". Его название и шаги не отражают конкретную функциональность или требование. Например, "Проверить работу кнопки" вместо "Проверить, что кнопка 'Отправить' валидирует email-поле и отправляет форму при корректных данных".
• Проверка нескольких несвязанных функций в одном кейсе (нарушение принципа атомарности): Это усложняет поддержку и локализацию дефекта. При падении такого кейса непонятно, какая именно часть функционала сломана.
• Неочевидные или избыточные проверки (Orphan Checks): В шагах присутствуют проверки, не связанные напрямую с целью теста. Например, при проверке логина в шагах фигурирует "Убедиться, что футер сайта содержит актуальный год".
• Незавершённость: Кейс не заканчивается явным утверждением о результате (ожидаемый результат), оставляя результат интерпретации на усмотрение исполнителя.

2. Структурные и технические проблемы

• Избыточная детализация (Over-specification): Кейс превращается в пошаговый мануал для пользователя, а не в чек-лист для тестировщика. Он жёстко фиксирует несущественные детали (точные названия кнопок, последовательность необязательных действий), что приводит к частым ложным падениям при любых минимальных изменениях UI.
• Жёсткая привязка к данным (Hardcoding): Конкретные тестовые данные (логины, ID, значения) вшиты в шаги. Это делает кейс невоспроизводимым при смене окружения или данных.

  # ПЛОХО: Жёсткая привязка
  Шаг 1: Ввести в поле "Логин" значение "test_user_123"
  Шаг 2: Ввести в поле "Пароль" значение "Qwerty123!"
  # ХОРОШО: Использование переменных/контекста
  Шаг 1: Ввести в поле "Логин" значение валидного логина
  Шаг 2: Ввести в поле "Пароль" значение валидного пароля
  

• Зависимость от контекста или других кейсов: Для выполнения кейса требуется предварительное ручное выполнение других сценариев ("Предусловие: выполнить тест-кейс TK-457"). Это нарушает независимость и усложняет автоматизацию.
• Отсутствие предусловий и постусловий: Не указано, в каком состоянии должна находиться система перед началом теста (например, "Пользователь зарегистрирован и не залогинен") и какие действия нужно выполнить для возврата системы в исходное состояние после теста (очистка данных).

3. Практическая бесполезность

• Дублирование функциональности: Кейс проверяет то же самое, что и другие существующие кейсы, но с незначительными вариациями данных. Это увеличивает объём работ без добавления ценности.
• Проверка тривиальных или невозможных сценариев: Создание кейсов на гипотетические ситуации, которые не отражены в требованиях или противоречат логике работы системы (например, "Проверить вход в систему с логином 'null'" без соответствующего требования).
• Невоспроизводимость: Кейс нельзя выполнить дважды подряд без дополнительных манипуляций из-за уникальности данных или неочищенных изменений состояния системы.
• Низкая эффективность по поиску дефектов (Low Defect Yield): Кейс, который годами выполняется и никогда не падает, может быть либо тривиальным, либо проверять сверхстабильный код, либо быть некорректно составленным. Стоит пересмотреть его необходимость.

4. Плохая читаемость и поддерживаемость

• Неоднозначные формулировки: Использование расплывчатых терминов: "проверить работу", "убедиться в корректности", "немного подождать". В хорошем кейсе всё измеримо и конкретно.
• Слишком общий ожидаемый результат: Результат "Форма отправляется" вместо "Появляется зелёное всплывающее уведомление 'Данные успешно сохранены', запись отображается в таблице личного кабинета".

Пример сравнения

## ПЛОХОЙ ТЕСТ-КЕЙС
ID: TK-001
Название: Проверить корзину
Шаги:
1. Открыть сайт.
2. Найти товар "iPhone 15".
3. Нажать на него.
4. Нажать кнопку "В корзину".
5. Перейти в корзину.
Ожидаемый результат: Всё работает.

## ХОРОШИЙ ТЕСТ-КЕЙС
ID: TK-007
Название: Проверка добавления товара в корзину для авторизованного пользователя.
Предусловие: Пользователь авторизован. Товар с ID=777 существует и есть в наличии.
Постусловие: Удалить товар из корзины.
Шаги:
1. Сохранить текущее количество товаров в корзине (из иконки хедера) как `initial_count`.
2. Перейти на страницу товара с ID=777.
3. Нажать кнопку "Добавить в корзину".
4. Дождаться появления тоста "Товар добавлен в корзину".
5. Перейти в раздел "Корзина" через хедер.
Ожидаемый результат:
- На странице корзины присутствует одна позиция: "Товар XYZ".
- Количество товаров в иконке корзины в хедере равно `initial_count + 1`.
- Общая сумма заказа рассчитана корректно (цена товара * 1).

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