В чем разница между тест-кейсом и баг-репортом?

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

Тест-кейс (Test Case) — это, блядь, священный план захвата. Как инструкция к микроволновке, только для софта. Ты заранее, пока ещё не охуел от количества багов, пишешь, как именно ты собираешься эту фичу проверять. По шагам, чётко, чтоб любой дурак, даже тот самый разработчик, который это написал, смог повторить.

Что внутри этого плана?

• Номер и название, чтобы не путать.
• Предусловия (типа "войди в систему, а то нихуя не получится").
• Конкретные шаги: "нажми сюда, введи то".
• И самое главное — Ожидаемый результат (Expected Result). Это твоя священная корова, истина в последней инстанции. Как ДОЛЖНО быть, если всё по уму сделано.

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

ID: TC-LOGIN-01
Title: Успешный вход с валидными учетными данными
Preconditions: Пользователь зарегистрирован в системе.
Steps:
1. Открыть страницу входа.
2. В поле 'Email' ввести 'user@example.com'.
3. В поле 'Пароль' ввести 'SecurePass123'.
4. Нажать кнопку 'Войти'.
Expected Result:
- Пользователь перенаправлен на главную страницу (/dashboard).
- В заголовке страницы отображается приветствие 'Добро пожаловать, User!'.

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

Баг-репорт (Bug Report) — это уже не план, а, простите за выражение, труп на месте преступления с фотографиями и показаниями свидетелей. Ты обнаружил, что что-то пошло не по плану, и теперь надо так вмазать описание проблемы разработчику, чтобы у него даже мысли не возникло сказать "а у меня всё работает".

Что внутри этого "трупа"?

• Заголовок, от которого у разработчика должно ёкнуть.
• Шаги воспроизведения, чтобы он сам мог наступить на эти грабли.
• Фактический результат (Actual Result) — та самая пизда, которая случилась в реальности.
• Ожидаемый результат (Expected Result) — то, что было в тест-кейсе, то есть как должно было быть. Без этого — доверия ёбать ноль, непонятно, баг это или твои фантазии.
• Всё остальное (логи, скриншоты) — это улики, которые не дадут тебе послать нахуй с формулировкой "не воспроизводится".

Вот как выглядит отчёт, когда наш красивый план TC-LOGIN-01 накрылся медным тазом:

Title: [Login Page] Пользователь не перенаправляется на dashboard после успешного входа
Severity/Priority: Major / High
Steps to Reproduce:
1. Открыть страницу входа (https://app.test.com/login).
2. Ввести валидный email: user@example.com.
3. Ввести валидный пароль: SecurePass123.
4. Нажать кнопку 'Войти'.
Expected Result: Редирект на /dashboard.
Actual Result: Пользователь остается на странице /login, в интерфейсе изменений нет. В консоли браузера ошибка 500 на запросе POST /api/login.
Environment: Chrome 120, Windows 11, Staging environment.
Attachments: [console_logs.txt], [screenshot_login_page_after_submit.png]

Итог, чтобы два раза не вставать: Тест-кейс — это твой план, как всё должно работать. Ты его пишешь ДО того, как начал ломать. А баг-репорт — это крик души и подробный отчёт о том, как этот самый план разъехался с реальностью, и что за пиздопроёбина из этого вышла. Первый — чтобы проверять, второй — чтобы чинить. Всё просто, ёпта.