Как формулировать шаги тест-кейса

Формулировка шагов тест-кейса: ключевые принципы и практика

Формулировка шагов тест-кейса — это основа качественной тестовой документации. Чёткие и однозначные шаги обеспечивают воспроизводимость теста, снижают риски неверной интерпретации и экономят время как на выполнение, так и на поддержку. Основная цель — сделать так, чтобы любой член команды (или даже автоматизированный скрипт) мог выполнить тест-кейс, получив один и тот же результат.

Основные правила формулировки шагов

1. Действие → Ожидаемый результат. Каждый шаг должен следовать этой структуре. Сначала описывается конкретное действие тестировщика или системы, затем — ожидаемая реакция системы.
2. Атомарность. Один шаг = одно законченное действие. Это облегчает локализацию дефекта, если он возник.
3. Однозначность и конкретность. Избегайте расплывчатых формулировок. Используйте точные названия элементов интерфейса, ID полей, URL, значения данных.

    *   **Плохо:** "Ввести логин".
    *   **Хорошо:** "В поле `Username` ввести значение `test_user_01`".

1. Использование утвердительной формы. Шаги описывают, что нужно сделать, а не чего делать не следует (если это не является сутью негативного теста).
2. Нумерация. Шаги нумеруются последовательно. Это удобно для ссылок в баг-репортах ("Падение на шаге 5").

Примеры: от плохого к хорошему

Пример 1: Проверка авторизации

# Плохо: расплывчато и неструктурированно
Шаги:
1. Открыть сайт и найти форму входа.
2. Попробовать залогиниться с неправильным паролем.
3. Увидеть, что система не пускает.

# Хорошо: конкретно, атомарно, с ожидаемым результатом
Предусловие: Пользователь с логином `demo` и паролем `Mode123` зарегистрирован в системе.
Шаги:
1. На главной странице `https://example.com` нажать кнопку **Sign In**.
2. В открывшейся модальной форме в поле `Email` ввести `demo@example.com`.
3. В поле `Password` ввести `WrongPassword`.
4. Нажать кнопку **Login**.
Ожидаемый результат: Под формой входа отображается красное сообщение об ошибке: `Invalid email or password`. Аутентификация не происходит, пользователь остается на текущей странице.

Пример 2: Тестирование функционала корзины (с использованием тестовых данных)

Шаги:
1. В строке поиска ввести "iPhone 13 Case" и нажать **Поиск**.
2. В результатах поиска нажать на карточку товара "Чехол iPhone 13, синий".
3. На странице товара нажать кнопку **Добавить в корзину**.
4. Нажать на иконку корзины в правом верхнем углу для перехода в неё.
Ожидаемый результат: В корзине отображается одна позиция: "Чехол iPhone 13, синий" с количеством `1` и корректной ценой.

Структура шагов для разных типов тестов

• Позитивные тесты: Шаги ведут по "счастливому пути". Действия корректны, ожидаемые результаты подтверждают работоспособность функционала.
• Негативные тесты: В одном из шагов сознательно совершается ошибочное действие (ввод неверных данных, нарушение бизнес-правила). Ожидаемый результат должен четко описывать, как система корректно обрабатывает эту ошибку (показывает сообщение, блокирует действие, не падает).
• Тесты на граничные значения: Шаги должны точно указывать тестовые данные. Например: "В поле Возраст, принимающее значения от 18 до 100, ввести 17". Ожидаемый результат: "Отображается валидационная ошибка Minimum age is 18".

Связь шагов с другими артефактами

• Предусловия (Preconditions): Описывают состояние системы, необходимое для начала теста (пользователь залогинен, создан заказ, включена настройка). Это позволяет не загромождать шаги.
• Постусловия (Postconditions): Описывают действия для возврата системы в исходное состояние (разлогин, удаление тестовых данных). Важно для обеспечения независимости тестов.
• Тестовые данные (Test Data): Часто выносятся отдельно или явно указываются в шагах. Для сложных данных лучше использовать ссылки на отдельный конфигурационный файл или таблицу.

  # Пример вынесенных тестовых данных (для автоматизации или сложных наборов)
  TEST_USERS = {
      'admin': {'login': 'admin@test.com', 'pass': 'SecurePass123', 'role': 'ADMIN'},
      'user': {'login': 'user@test.com', 'pass': 'UserPass456', 'role': 'USER'}
  }
  

Практические советы для отличных шагов

• Пишите для "своего будущего я" и коллег. Через полгода должно быть всё так же понятно.
• Избегайте местоимений. Вместо "нажать на него" пишите "нажать кнопку Сохранить".
• Используйте стиль, близкий к Given-When-Then (Gherkin), даже если не используете BDD-фреймворки. Это дисциплинирует мышление.
• Рецензируйте тест-кейсы. Коллегический review помогает выявить неоднозначности.
• Для UI-тестов делайте скриншоты или указывайте уникальные локаторы в ожидаемых результатах, особенно для сложных интерфейсов.

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