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

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

Так, значит, первым делом — этот самый Сводный отчёт о тестировании, он же Test Summary Report. Это такая бумажка, которую ты суёшь всем стейкхолдерам, чтобы они не думали, что ты всю неделю хуярил в танчики. Там надо коротко, но ёмко, чтобы даже менеджер, у которого вместо мозга excel-таблица, всё понял.

Смотри, как это примерно выглядит, блядь:

## Test Summary Report for Sprint 12

**Общее покрытие:** 92% (API), 78% (UI)
**Статистика по дефектам:**
- Новые: 15 (2 Critical, 5 High, 8 Medium)
- Исправленные: 10
- Открытые: 7
**Риски:** Задержка в тестировании интеграции с внешним сервисом X.
**Рекомендации:** Увеличить покрытие E2E-тестами для модуля оплаты.

Видишь? Всё чётко. Покрытие показал, баги посчитал, на риски пальцем ткнул — мол, смотрите, суки, из-за этого вашего кривого сервиса X мы все сроки просрали. И рекомендацию впилил, чтобы в следующем спринте дали время на нормальные тесты, а не эту тяп-ляп хуйню.

Дальше, второй пункт — актуализация тестовых артефактов. Это, блядь, самая нудная часть, но без неё — пиздец полный потом.

• Тест-кейсы и чек-листы: Те, что для новой фичи написал — добавляешь. Старые, которые больше не работают, потому что разработчики всё перелопатили — либо обновляешь, либо в архив отправляешь, нахуй. Чтобы не запутаться и не тестировать по сценарию, который уже лет пять как не актуален.
• Баг-репорты: Здесь вообще веселье. Надо все баги, которые нашли, привести в божеский вид. Закрытые — проверить, точно ли пофикшены, или разработчик просто статус сменил, надеясь, что ты не заметишь. Открытые — чтобы все видели, какой там пиздец ещё предстоит починить. Это чтобы не было такого: "А мы думали, это уже исправлено!" — "Да идите вы нахуй, я же репорт писал!"
• Документация по тестовым данным и окружению: Тут тоже важно. Если что-то поменялось (например, логины-пароли тестовые или настройки стенда), надо всё записать. А то придёт новый тестировщик и будет неделю ебаться, пытаясь понять, почему у него ничего не работает.

Третий момент — материалы для ретроспективы команды. Вот это, блядь, святое. Тут надо не стесняться. Писал фичу — а тебе окружение падало полдня? Пиши. Ждал билд три часа? Пиши. Инструмент для логирования такой говённый, что глаза кровоточат? Обязательно пиши! Это не чтобы начальству нажаловаться, а чтобы всем вместе понять, где процесс дал трещину, и как его починить. Фокус на проблемах, а не на людях, хотя иногда хочется, вротберунчик...

И наконец, четвёртое — демонстрационные материалы. Скриншоты, короткие видео, готовые сценарии. Это чтобы когда продукт-оунер или заказчик придут на демку и спросят: "А что тут нового?", можно было не пиздеть полчаса, а просто показать: "Вот, смотри, раньше кнопка была зелёная, а теперь — синяя, и при нажатии играет гимн России. Всё протестировано". Им же похуй на метрики, им наглядно надо.

Вот такая, блядь, матрёшка получается. Вся эта писанина — она не для галочки, а чтобы следующий спринт начинать не с пустого места, а с понимания, что сделано, что сломано и куда дальше двигаться. Прозрачность, ебать, процессная. Хуйня, конечно, но без неё — совсем пиздец.