Перейти на PRO

Какая обязательная информация должна быть в тест-кейсе?

Тип вопроса: Тестовая документация Вероятность: 10% Категория: QA Тестировщик

Ответ

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

Обязательные поля тест-кейса:

  1. Уникальный идентификатор (ID)

    • Например: TC-AUTH-001, LOGIN_01. Нужен для однозначной ссылки и трассируемости.

  2. Название (Title/Summary)

    • Краткое, но информативное описание цели теста.
    • Плохо: "Проверка кнопки".
    • Хорошо: "Проверка успешной авторизации с валидным email и паролем".

  3. Предусловия (Preconditions)

    • Условия, которые должны быть выполнены до начала теста.
    • Пример: "Пользователь зарегистрирован в системе. Известны валидные email (test@example.com) и пароль."

  4. Шаги выполнения (Test Steps)

    • Чёткая, пронумерованная последовательность действий тестировщика.
    • Каждый шаг должен начинаться с глагола.
    • Пример:
      1. Открыть страницу авторизации (/login).
      2. В поле "Email" ввести test@example.com.
      3. В поле "Password" ввести Qwerty123!.
      4. Нажать кнопку "Sign In".

  5. Ожидаемый результат (Expected Result)

    • Описание того, что должно произойти после выполнения всех шагов.
    • Должен быть конкретным и проверяемым.
    • Пример: "Пользователь перенаправлен на страницу личного кабинета (/dashboard). В верхнем правом углу отображается приветствие 'Hello, Test User!'."

Дополнительные/служебные поля (заполняются в процессе):

  • Фактический результат (Actual Result): Что произошло на самом деле во время выполнения.
  • Статус (Status): Passed, Failed, Blocked, Skipped.
  • Приоритет (Priority): High, Medium, Low.
  • Связанные артефакты: Ссылка на требование, дефект, тестовые данные.

Пример тест-кейса в формате Markdown:

**ID:** TC-LOGIN-01
**Название:** Успешная авторизация с валидными учётными данными.
**Приоритет:** High
**Предусловия:**
1. Пользователь с email `test.user@domain.com` и паролем `SecurePass123` зарегистрирован в системе.
2. Приложение запущено, доступна страница `/login`.

**Шаги выполнения:**
1. На странице авторизации в поле "Email" ввести `test.user@domain.com`.
2. В поле "Password" ввести `SecurePass123`.
3. Нажать кнопку "Login".

**Ожидаемый результат:**
1. Происходит перенаправление на URL `/dashboard`.
2. На странице отображается текст "Welcome, Test User!".
3. В заголовке окна браузера отображается "My Dashboard".

**Фактический результат:** [Заполняется при выполнении]
**Статус:** [Passed/Failed/Blocked]
**Связанный дефект:** [JIRA-BUG-XXX, если тест упал]

Ответ 18+ 🔞

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

Вот что обязательно должно быть в нормальном тест-кейсе, иначе это просто хуйня на постном масле:

Без чего твой кейс — говно:

  1. ID (Уникальный номер)

    • Это как татуировка, блядь. TC-LOGIN-01, AUTH-1337. Чтобы потом не орать по офису: "Эй, пидарас, про какой именно кейс с авторизацией ты говоришь? Их у меня овердохуища!".

  2. Название (Title)

    • Оно должно быть таким, чтобы сразу было понятно, куда смотреть. Не "Проверить кнопку", ёпта. Это пиздец какой-то.
    • Хуёво: "Тест поля".
    • Нормально: "Проверка, что при вводе валидного email и пароля пользователь авторизуется".

  3. Предусловия (Preconditions)

    • Это что нужно сделать до того, как ты начал жать кнопки. Чтобы не было ситуации: "А хули у меня не работает?" — "А ты пользователя-то создал, мудень?".
    • Пример: "В базе есть юзер с логином ivanov@test.com и паролем Qwerty123!. Браузер открыт."

  4. Шаги (Test Steps)

    • Чёткая инструкция, как обезьяна с гранатой. По пунктам. "Нажми сюда, введи туда". Каждый шаг — это глагол, блядь. Не "Поле для email", а "В поле 'Email' ввести test@example.com".
    • Пример, который поймёт даже мартышлюшка:
      1. Открыть страницу /login.
      2. В поле "Логин" вписать ivanov@test.com.
      3. В поле "Пароль" вписать Qwerty123!.
      4. Ткнуть кнопку "Войти".

  5. Ожидаемый результат (Expected Result)

    • А вот это самое важное, блядь! Что должно случиться в идеальном мире, где разработчики не ебланы? Конкретика! Не "Всё работает", а "Пользователь попадает на страницу /profile. В правом верхнем углу появляется надпись 'Привет, Иван!'".

Поля, которые заполняются потом (когда уже всё пошло по пизде или нет):

  • Фактический результат: Что случилось на самом деле. "Вместо профиля вылезла ошибка 500, и сервер накрылся медным тазом".
  • Статус: Passed (ура, работает), Failed (всё сломалось, пиздец), Blocked (нельзя проверить, потому что...).
  • Приоритет: High (ломается — всем пизда), Low (ну сломалось и сломалось, похуй).
  • Ссылка на баг: Если тест упал, сюда пишем номер дефекта, чтобы разработчику было куда идти и что чинить.

Вот, смотри, как это выглядит вживую:

**ID:** TC-LOGIN-01
**Название:** Успешный вход в систему с валидным логином и паролем.
**Приоритет:** High
**Предусловия:**
1. В системе существует активный пользователь с логином `demo@test.ru` и паролем `Demo123!`.
2. Браузер открыт на главной странице.

**Шаги выполнения:**
1. Нажать на кнопку "Войти" в шапке сайта.
2. В открывшейся форме в поле "Email" ввести `demo@test.ru`.
3. В поле "Пароль" ввести `Demo123!`.
4. Нажать кнопку "Отправить".

**Ожидаемый результат:**
1. Происходит перезагрузка страницы.
2. Кнопка "Войти" в шапке меняется на "Мой профиль".
3. В консоли браузера отсутствуют ошибки (код ответа 200).

**Фактический результат:** [Тут пишешь, что увидел]
**Статус:** [Passed/Failed/Blocked]
**Связанный дефект:** [JIRA-666, если всё поломалось]

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

© ХакСобесов, 2026
support@hacksobesov.com