Из каких источников формируется тестовая документация на проекте?

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

Вот представь: приходишь ты на проект, а там — хуй, полная пустота. Ни тебе спецификаций, ни историй, нихуя. Просто есть какая-то штука, которая вроде работает, а вроде и нет. И первая мысль: «Ёпта, где ж я возьму хоть что-то, чтобы понять, что тут вообще должно происходить?»

Так вот, источники-то, они как будто есть, но собрать их — это отдельный квест, блядь.

• Бизнес-требования? Ну, в теории — да, User Stories от аналитика. А на практике это чаще всего три строчки в Jira: «Сделать кнопку, чтобы всё летало». И всё, пиздец. Приходится самому лезть к продакту и выпытывать: «А что, блядь, под «летало» имеется в виду? Чтобы ракеты в космос запускались или просто чтоб не падало с ошибкой 500?»
• Техническая документация? Ха! Если повезёт, будет какая-нибудь схема, нарисованная на салфетке. Или Swagger, который обновляли в прошлой жизни. Архитектурная схема? Да это обычно один квадратик с надписью «Сервис», от которого стрелочка ведёт в другой квадратик «База», и всё, ебать мои старые костыли.
• Коммуникация в команде? Вот это — реальный кладезь, но и минное поле одновременно. На митингах говорят одно, в слаке пишут другое, а в комментариях к задаче — третье. И ты сидишь, как тот самый Герасим, и думаешь: «Му-му... То есть, какую ж из этих версий, блядь, в тест-кейс писать?»
• Исторические данные? Вот это — святое. Старые баг-репорты — это как учебник выживания. Смотришь, где раньше всё ебнулось, и сразу понимаешь, куда в первую очередь тыкать палкой. Без этого — вообще никуда.

А теперь смотри, как это всё «структурируется» в том же Confluence. Выглядит, конечно, охуенно солидно:

1.  Обзор продукта и цели тестирования
2.  Тестовые среды и данные
3.  Чек-листы для smoke- и регрессионного тестирования
4.  Детальные тест-кейсы для критичных функций
5.  Отчеты о результатах тестирования

Но правда в том, что 90% времени пункт первый — «Обзор продукта» — ты пишешь САМ, методом, прости господи, reverse-engineering. То есть ты просто открываешь это чудо-юдо, начинаешь жать на все кнопки подряд, смотреть, что куда летит, и конспектировать: «Ага, сука, вот эта штука зовётся «Профиль пользователя», а вот эта — «Корзина». И вроде бы они как-то связаны. Запись!»

И вот из этого хаоса, из обрывков фраз в чате, из старых багов и твоих личных открытий рождается документ. Сначала он — твой личный спасательный круг, чтобы не сойти с ума. А потом оказывается, что это — единственный на весь проект источник правды о том, как эта бандура на самом деле работает.

Так что да, идеальной документации не бывает. Бывает документ, который ты выстрадал, выебался с ним, и который теперь все называют «истиной в последней инстанции». Потому что кроме тебя нихуя никто не знает, что там и как. Вот такая, блядь, поэзия.