Какую документацию необходимо создавать на этапе анализа требований для тестирования?

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

Итак, какие бумажки нам тут жизненно необходимы, чтобы не оказаться в положении «я думал, ты думал»:

1. Спецификация или истории (SRS / User Stories). Это, сука, святое. Формализованные ожидания. Не «ну чтоб работало», а чётко: кто, что и зачем. Вот смотри, пример этой истории, чтоб понятно было:

   Как: зарегистрированный пользователь
   Чтобы: отслеживать статус заказа
   Я хочу: видеть страницу "Мои заказы" с историей и текущими заказами

   Видишь? Уже не «сделайте кнопочку», а конкретный сценарий. С этого и начинается нормальная работа, а не гадание на кофейной гуще.

2. Чек-листы высокого уровня. Это не детальные шаги, а группы проверок, типа «Всё, что связано с авторизацией» или «Основные сценарии покупки». Чтобы с одного взгляда понять, какие вообще блоки есть. Без этого можно так углубиться в одну кнопку, что про весь интерфейс забудешь, пидоры.

3. Матрица трассируемости (RTM). О, это наше всё, блядь! Табличка, которая связывает каждое требование из пункта 1 с конкретными тест-кейсами. Её главная магия — гарантия, что нихуя не упустили. Каждое требование покрыто тестами. Если требования поменялись — сразу видно, какие тесты надо переписать. Без неё — овердохуища ручного труда и дыр в покрытии.

4. Глоссарий проекта. Казалось бы, мелочь. Ан нет! Пока все не договорятся, что «корзина» — это «cart», а не «basket», и что статус «в обработке» означает А, Б и В, а не Х, У и Z, можно насоздавать столько недопониманий, что мама не горюй. Это чтобы вся команда говорила на одном языке, а не как мартышлюшки.

5. Прототипы и макеты (UI/UX). Ну тут всё ясно. Чтобы проектировать UI-тесты, надо понимать, как эта штука должна выглядеть. Иначе как проверять-то? На глазок? Да похуй, что ли?

А теперь, внимание, критерии качества этой всей документации. Если они не выполняются — это пиздец, а не этап анализа:

• Однозначность. Требования должны быть сформулированы чётко: ЕСЛИ (условие) -> ТО (результат). Никаких «может быть», «скорее всего» и «как-нибудь». Иначе тестируемость — ноль ебать.
• Тестируемость. Самое главное! Для каждого требования должен существовать объективный способ проверить, выполнено оно или нет. Если нельзя придумать тест — требование хуёвое, иди переписывай.
• Доступность. Все эти документы должны лежать не в почте у Васи или на флешке у Пети, а в одном общем месте. Confluence, Wiki, SharePoint — не важно. Главное, чтобы любой мог найти актуальную версию за 30 секунд, а не искал полдня.
• Версионность. Изменения — это норма. Но они должны отслеживаться. Должно быть ясно, какая версия документа сейчас в силе, что поменяли и когда. Иначе начнётся: «А я работал со старой спецификацией!». Вот тогда и начинается настоящий пиздец, в рот меня чих-пых.

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