Перейти к основному содержимому

Тест-кейсы: как и зачем писать

Тест-кейс — это подробный алгоритм действий, по которому нужно проверять разработанный функционал.

Виды тест-кейсов​

  • Позитивные (положительные): Проверяют, что система правильно реагирует на корректные данные. Пример: пользователь существует в системе и он может пройти авторизацию.

  • Негативные (отрицательные): Показывают, что система умеет работать с некорректными данными. Пример: пользователь при регистрации ввёл простой пароль 12345, а кнопка “Установить пароль” активной не стала, так как ждёт более сложный.

  • Деструктивные: Служат для проверки прочности системы. Пример: метод для получения заказов пользователя нельзя выполнить без авторизации.

Особенности​

  • Идеально подходят для описания сложных проверок в системе и регрессионного тестирования.
  • Помогают автоматизировать ручные проверки, если тестирование занимает много времени.
  • Используются для проверки системы не тестировщиками, для онбординга новых людей на проект.
  • Помогают определить необходимое время на тестирование.
  • Избыточны для небольших задач.
  • Требуют много времени на написание и актуализацию.
  • Может возникнуть "Эффект пестицида" — когда из-за постоянного повторения одинаковых шагов не получается найти ошибки.

Содержание тест-кейса​

  • Уникальный номер: Позволит ссылаться на тесты по номеру.
  • Заголовок: Отражает цель - что именно нужно проверить.
  • Предусловия: Что нужно сделать перед началом тест-кейса.
  • Постусловия (редко): Что нужно сделать после проведения проверки. Например, удалить изменения из базы данных.
  • Шаги: Что нужно сделать для проверки.
    • Не описывать шаги слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
    • Шаги должны быть конкретными. Написать: “Нажмите на иконку пользователя → Личный кабинет” вместо “Зайдите в личный кабинет”.
    • Скриншоты можно использовать только как дополнение к текстовому описанию.
  • Ожидаемый результат: Что должно получиться после или во время прохождения шагов.
  • Статус: Passed/Failed, то есть Успех/Провал или другой. Отмечается при прохождении кейса тестировщиком.

Use Case vs Test Case​

  • Use Case: Детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты. Используется для описания функциональных требований к системе.
  • Test Case: Детальное описание того, как должно проходить тестирование конкретной функции в системе. Основываются на юскейсах и используются для проверки соответствия реализации требованиям.

Аналитик и тест-кейсы​

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

Инструменты ведения для тест-кейсов​

  • Zephyr for Jira
  • TestRail
  • Qase
  • Test IT

Подборка материалов​

Статьи​

  1. Что такое тест‑кейс, зачем он нужен и как его писать
  2. Как писать тест-кейсы
  3. Тест-кейс. QA_Bible
  4. Покрытие требований кейсами. Реалии компании SuperJob
  5. Пишем максимально эффективный тест-кейс
  6. 10 инструментов QA-инженера для ручного тестирования
  7. Основные методики создания тест-кейсов
  8. Правила написания предварительных шагов в тест-кейсах

Видео​

  1. Что такое тест-кейсы и как их писать: правила и примеры
  2. Идеальный Баг Репорт в Jira, Тест Кейс в TestRail
  3. Тестовая документация. Чек-лист и тест-кейс в тестировании
  4. 5 атрибутов хорошего тест-кейса. Тест-кейсы в TestRail
  5. Тест-кейсы в тестировании / Тестировщик с нуля

Книги​

  1. Ольга Назина. Что такое тестирование. Курс молодого бойца
  2. Тестирование программного обеспечения. Базовый курс