Какая документация создаётся на каждом этапе классического цикла тестирования ПО?

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

Так, слушай, что у нас тут по этапам.

1. Планирование — когда все ещё верят в светлое будущее. Тут рождается тест-план. Это такой документ, в котором мы расписываем, что будем тестировать, как, на чём и, самое главное, когда уже можно будет пойти на перекур. Там же матрица трассируемости — хуёвая табличка, которая связывает каждое требование заказчика с тест-кейсом. Нужна, чтобы когда что-то сломается, можно было ткнуть пальцем и сказать: «Вот, Петрович, смотри, требование №3.45б — нихуя не работает, а мы тестировали!».

2. Анализ и дизайн — когда эйфория проходит и начинается осознание, что всё сложно. Тут уже ближе к делу. Чек-листы — для тех, кто не любит долго думать, или когда требования меняются быстрее, чем ты успеваешь кофе выпить. Просто список: сделал галочку — иди дальше. Тест-кейсы — это уже серьёзно. Пошаговые инструкции, как довести систему до белого каления. «Шаг 1: введи логин. Шаг 2: введи пароль. Шаг 3: получи по ебалу ошибкой, если пароль — "12345"». А ещё есть спецификации тест-дизайна. Звучит умно, а на деле — просто описание, как мы будем выёбываться с таблицами решений или диаграммами, чтобы покрыть все возможные сценарии. Иногда полезно, иногда — овердохуища работы на ровном месте.

3. Реализация и выполнение — адский труд, когда руки уже чешутся всё сломать. Пишем автоматизированные скрипты. Это когда ты три дня пишешь код, который за две секунды проверит то, на что вручную ушло бы полчаса. Чувствуешь себя богом, пока скрипт не сломается на первом же шаге. Готовим наборы тестовых данных. «Вася Пупкин», «test@test.com», «Qwerty123!». Мечтаешь, чтобы в реальной жизни все пользователи были такими же предсказуемыми. Находим баг — пишем отчёт о дефекте. Главное — описать шаги так, чтобы разработчик, который в три часа ночи будет это читать, не захотел тебя найти и впендюрить. «Шаги: 1. Открыть приложение. 2. Нажать на кнопку "Сломать всё". 3. Увидеть, что всё сломалось. Ожидаемый результат: всё не должно ломаться». Гениально. И, конечно, логи выполнения — горы текста, в которых потом будешь искать, почему же тест упал. «А, так тут память кончилась, пока он пытался загрузить фотографию твоей мамаши в разрешении 8K».

4. Завершение — когда уже всё равно, лишь бы отпустили. Пишем финальный отчёт. «Дорогие начальники, мы протестировали. Что-то работает, что-то нет. Вот графики. Вот выводы. Можно нам теперь зарплату?». Считаем метрики качества. «Покрытие требований — 85%». Это значит, что 15% функционала мы или проебали, или забили хуй, потому что там и так всё понятно (спойлер: там как раз всё сломается у первого же пользователя).

А вот, смотри, пример чек-листа для авторизации, чтоб ты понимал, о чём речь:

- [ ] Успешный вход с валидными учётными данными.
- [ ] Ошибка при вводе неверного пароля.
- [ ] Ошибка при вводе несуществующего логина.
- [ ] Валидация полей ввода (пустые значения, спецсимволы).

Выглядит просто, да? А теперь представь, что поле пароля принимает спецсимволы, но база данных их нихуя не экранирует, и при попытке входа ' OR '1'='1 тебя пускает в систему без пароля. Вот тут-то и начинается веселье, ёпта! Вся эта документация — чтобы такие сюрпризы если уж не предотвратить, то хотя бы задокументировать и тыкнуть потом носом того, кто это написал.