Тест-кейсы и баг-репорты правильно

Как правильно писать тест-кейсы и баг-репорты: структура, обязательные поля, шаги воспроизведения и приоритеты. Практический разбор с примерами для начинающего QA.

Коротко. Хороший тест-кейс — это чёткие шаги + ожидаемый результат, которые сможет повторить любой. Хороший баг-репорт отвечает на «что сломалось, как повторить, что ожидалось». Главное — воспроизводимость: если баг нельзя повторить по вашему описанию, его не починят.

Структура тест-кейса

ID и название — коротко о проверке.
Предусловия — что должно быть готово.
Шаги — пронумерованные действия.
Ожидаемый результат — что должно произойти.

Пример тест-кейса

Название: Авторизация с верными данными
Предусловие: пользователь зарегистрирован
Шаги:
  1. Открыть страницу входа
  2. Ввести корректные логин и пароль
  3. Нажать "Войти"
Ожидаемый результат: вход выполнен, открыт личный кабинет

Структура баг-репорта

Заголовок — суть проблемы одной строкой.
Шаги воспроизведения — по пунктам.
Фактический результат — что произошло.
Ожидаемый результат — что должно было.
Окружение — браузер, ОS, версия.
Вложения — скриншот/видео/логи.

Severity и Priority

Параметр	О чём
Severity (критичность)	Насколько серьёзен дефект технически
Priority (приоритет)	Насколько срочно чинить с точки зрения бизнеса

Они не всегда совпадают: опечатка в логотипе на главной — низкая severity, но высокий priority.

Частые вопросы

Что важнее в баг-репорте?
Воспроизводимость. Точные шаги + окружение + скриншот экономят время разработчику.

Сколько шагов в тест-кейсе?
Столько, сколько нужно для однозначного повторения. Обычно 3–8; слишком длинные лучше разбить.

Где вести кейсы и баги?
Баги — в Jira или аналоге, кейсы — в тест-менеджмент системах (TestRail, Allure TestOps) или таблицах на старте.