Как будешь записывать шаг проверки в тест-кейсе

Структура и подход к записи шага проверки в тест-кейсе

Запись шага проверки — это фундаментальный элемент создания эффективного и воспроизводимого тест-кейса. Каждый шаг должен быть четким, атомарным и однозначным, чтобы любой член команды (тестировщик, разработчик, аналитик) мог его однозначно понять и выполнить. Вот мой подход, основанный на принципах чтобы что (Given-When-Then) и стандартах IEEE 829.

Ключевые принципы составления шага

1. Атомарность: Один шаг = одно конкретное действие или одна проверка.
2. Однозначность: Использование точных формулировок, названий элементов интерфейса (ID, текста кнопок) и данных.
3. Воспроизводимость: Шаг должен содержать всю необходимую информацию для выполнения без дополнительных уточнений.
4. Структурированность: Логическое разделение действий и ожидаемых результатов.

Базовая структура шага проверки

Обычно я использую формат из двух-трех столбцов в тест-кейсе (Step / Test Data / Expected Result) или следующую текстовую структуру:

1. Действие (Action): Что делает тестировщик или система.
2. Тестовые данные (Test Data, опционально): Конкретные входные значения.
3. Ожидаемый результат (Expected Result): Как система должна отреагировать на действие.

Примеры записи шагов в разных контекстах

Пример 1: UI-тестирование формы логина

НЕПРАВИЛЬНО (расплывчато):

• Шаг 1: Ввести данные в форму.
• Шаг 2: Нажать кнопку.
• Шаг 3: Проверить, что все ок.

ПРАВИЛЬНО (четко и атомарно):

В текстовом формате это выглядит так:

Тест-кейс: Успешная авторизация с валидными данными.

1. Действие: Открыть страницу авторизации https://app.example.com/login.

    *   **Ожидаемый результат:** Отображается форма логина, содержащая поля "Email" и "Пароль", кнопку "Войти".

1. Действие: В поле с лейблом "Email" ввести валидный email адрес: user@example.com.

    *   **Ожидаемый результат:** Поле "Email" содержит введенный текст.

1. Действие: В поле с лейблом "Пароль" ввести валидный пароль: Qwerty123!.

    *   **Ожидаемый результат:** Введенные символы отображаются скрытыми (маскируются символами `•`).

1. Действие: Кликнуть левой кнопкой мыши по кнопке с текстом "Войти".

    *   **Ожидаемый результат:**
        *   Происходит переход на URL: `https://app.example.com/dashboard`.
        *   На странице отображается сообщение: "Добро пожаловать, User!".
        *   В хедере страницы отображается аватар пользователя.

Пример 2: API-тестирование (REST)

Для API-тестов шаги записываются более технически, с акцентом на запросы и ответы.

Тест-кейс: Создание нового ресурса через POST-запрос с валидным телом.

1. Действие: Выполнить HTTP POST запрос на эндпоинт.

    *   **Тестовые данные:**
        *   URL: `https://api.example.com/v1/users`
        *   Headers: `{ "Content-Type": "application/json", "Authorization": "Bearer <valid_token>" }`
        *   Body (JSON):

    ```json
    {
      "name": "John Doe",
      "email": "john.doe@example.com",
      "role": "subscriber"
    }
    ```

    *   **Ожидаемый результат:**
        *   **Статус код ответа:** `201 Created`.
        *   **Тело ответа (JSON)** содержит поля `id` (сгенерированный числовой идентификатор), `name`, `email`, `role`, соответствующие отправленным данным, а также поле `createdAt` с текущей timestamp.
        *   **Заголовок ответа** содержит `Location: https://api.example.com/v1/users/<new_user_id>`.

Пример 3: Проверка негативного сценария (валидация)

Тест-кейс: Попытка авторизации с некорректным паролем. ... (предыдущие шаги заполнения email) ... 4. Действие: В поле "Пароль" ввести строку, не соответствующую паролю пользователя.

    *   **Тестовые данные:** `WrongPassword123`

1. Действие: Нажать кнопку "Войти".

    *   **Ожидаемый результат:**
        *   **Без перезагрузки страницы** под формой логина появляется сообщение об ошибке красного цвета: "Неверный email или пароль".
        *   Поля "Email" и "Пароль" остаются заполненными введенными данными (пароль — в скрытом виде).
        *   **Статус код** сетевого запроса (видимый в DevTools) — `401 Unauthorized`.

Рекомендации и лучшие практики

• Используйте уникальные идентификаторы: Там, где это возможно, ссылайтесь на ID элемента (#login-button), а не только на его текст.
• Избегайте местоимений: Вместо "ввести в него" пишите "ввести в поле 'Пароль'".
• Предусловия и постусловия: Явно указывайте необходимые начальные состояния системы (например, "Пользователь с email user@example.com существует и активен") в отдельном разделе Preconditions. Аналогично для очистки данных после теста — в Postconditions.
• Связь с требованиями: Каждый шаг, особенно проверка ожидаемого результата, должен быть связан с конкретным функциональным требованием или пользовательской историей (через Requirement ID или ссылку).
• Автоматизация: Если тест-кейс планируется к автоматизации, формулировки шагов должны быть максимально близки к будущим командам в коде (например, click(By.id("submit")), assertTitleContains("Welcome")).

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