Какие виды документации использует тестировщик в работе?

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

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

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

Чек-листы (Checklists) А это уже для ленивых, или для тех, кому надо быстро всё проверить, пока начальство не пришло. Нет там этих «нажми сюда, введи туда». Просто список: «Логин работает? — галочка. Логаут работает? — галочка. Всё не разъехалось? — галочка». Идеально для регресса, когда уже всё сто раз проверили, но надо убедиться, что новое говно ничего старого не сломало.

Тест-план (Test Plan) О, это уже документ для больших шишек, блядь. Там не про то, как кнопку тыкать. Там стратегия, объёмы, ресурсы, сроки и прочая высокая материя. Пишется один раз в начале проекта, а потом про него все благополучно забывают, потому что сроки уже горят, а план, блядь, нереалистичный. Но он должен быть! Для галочки, понимаешь?

Баг-репорт (Bug Report) Вот это, сука, наше всё! Наше оружие, наша песня! Если написать его криво — разработчик тебе его в сраку засунет и скажет «не воспроизводится». Поэтому тут надо чётко, ясно и без воды: что делал, что получил, а что хотел получить. И обязательно окружение указать, а то он у себя на маке проверит, а у тебя на линуксе всё падает. Серьёзность (Severity) — это насколько баг страшный (вся система легла или кнопка на пиксель съехала). Приоритет (Priority) — насколько срочно его чинить (прям щас или когда-нибудь после дождичка в четверг).

Требования (SRS/User Stories) А это, блядь, священное писание, против которого мы и воюем. Если в требованиях написано «кнопка должна быть зелёная», а она красная — это баг. Если в требованиях не написано про кнопку вообще, а она есть — это уже фича-реквест, иди лесом. Часто бывает, что требования написаны так, что нихуя не понятно, и тогда начинается весёлая жизнь с уточнениями и спорами.

Матрица трассируемости требований (RTM) Ну это вообще, ёпта, высший пилотаж бюрократии. Большая таблица, где каждое требование привязано к тест-кейсам, которые его проверяют. Нужна, чтобы потом орать «А ВОТ ЭТО ТРЕБОВАНИЕ МЫ НЕ ПРОВЕРЯЛИ, ПОЭТОМУ ВСЁ УПАЛО!». В маленьких проектах на это обычно всем похуй, а в больших — без неё никуда, иначе овердохуища всего не отследить.

Ну и вот тебе пример, как этот самый тест-кейс выглядит, чтобы ты не думал, что мы там стихи пишем:

**ID:** TC-LOGIN-01
**Название:** Успешная авторизация с валидными данными
**Предусловие:** Пользователь зарегистрирован в системе.
**Шаги:**
1. Перейти на страницу /login.
2. В поле "Email" ввести "user@example.com".
3. В поле "Пароль" ввести "Qwerty123!".
4. Нажать кнопку "Войти".
**Ожидаемый результат:** Пользователь перенаправлен на страницу /dashboard. В заголовке страницы отображается "Личный кабинет".

Вот, смотришь на это, делаешь по шагам, и если тебя не пустило в кабинет, а выкинуло с ошибкой «ёбаный насос» — поздравляю, ты только что нашёл баг, сабака сука! Беги писать репорт, пока не забыл шаги.