# Лабораторная 05: ТЕСТИРОВАНИЕ И МЕТРИКИ

> Спринт 5 · Недели 11–12 · 14 дней · 10 баллов

**Вопрос спринта:** Достигаем целей?

Ответить цифрами: North Star против цели, финальные evals против критериев успеха, система против нагрузки, продукт против атак. Спринт доказательств.

## Формат сдачи

- Pull Request от каждой роли
- Ветка: `lab5-[role]-testing`
- Заголовок PR: `Lab5: [Role] — Testing Deliverables`

## Роли и шаги

### PRODUCT / VO — Приёмка по North Star

Отвечает за главный ответ спринта: достигли ли мы того, что обещали в лабе 1 — и что говорим об этом на Demo Day.

#### Шаг 1. Замер North Star (3–4 часа)

_Цель, поставленная в лабе 1, встречается с фактом._

- North Star измерена тем способом, что записан в критериях
- Факт против цели — без прилагательных, цифрами
- Причины расхождения — честно

**Сдаёшь:** Анализ достижения целей [документ] → `docs/goals-analysis.md`

#### Шаг 2. Приёмка продукта (3–4 часа)

_Финальная сверка продукта с болями из PRD._

- Каждая боль: закрыта / частично / нет — с примером
- Каждый UC работает на проде

**Сдаёшь:** Протокол приёмки [документ] → `docs/acceptance-final.md`

#### Шаг 3. План доработок (2–3 часа)

_Между лабой 5 и Demo Day есть время ровно на главное._

- Доработки, влияющие на демо, — в приоритет
- Остальное — в бэклог после курса

**Сдаёшь:** План доработок [документ] → `docs/improvements-plan.md`

#### Шаг 4. Нарратив результата (2–3 часа)

_История для Demo Day складывается из цифр этого спринта._

- Каркас истории: боль, решение, цифры
- Черновик ключевых слайдов

**Сдаёшь:** Нарратив для Demo Day [документ] → `docs/demo-narrative.md`

**Советы:** Цифра против цели — единственный честный итог · Частично закрытая боль — это тоже результат · Демо решает главное — доделывай для демо · Историю пишет тот, у кого есть цифры

### AI ENGINEER — Финальные метрики и ablation

Отвечает за финальные цифры модели и понимание, что именно их дало: ablation вместо «мы много старались».

#### Шаг 1. Финальный прогон метрик (4–5 часов)

_Последняя точка на графике качества за семестр._

- Полный eval-прогон финальной версии
- Динамика от лабы 3 к лабе 4 и к сегодняшнему дню
- Latency и стоимость сценария — фактические

**Сдаёшь:** Финальные метрики модели [документ] → `docs/ml-final-metrics.md`

#### Шаг 2. Ablation: что дало прирост (5–6 часов)

_Знание, что сработало, ценнее самого прироста._

- Отключаем улучшения по одному — меряем вклад
- Топ-3 решения по вкладу в качество
- Что не сработало — тоже вывод

**Сдаёшь:** Ablation-исследование [ноутбук] → `notebooks/ablation.ipynb`

#### Шаг 3. Последняя миля качества (4–5 часов)

_Дешёвые улучшения перед демо ещё возможны — дорогие уже нет._

- Точечные фиксы по плану доработок
- Каждый фикс подтверждён прогоном

**Сдаёшь:** Фиксы последней мили [код] → `ml/`

#### Шаг 4. Документация AI-части (2–3 часа)

_AI-часть должна быть объяснима без автора._

- Промпты, пайплайн, параметры — задокументированы
- Как воспроизвести метрики — по шагам

**Сдаёшь:** Документация AI [документ] → `docs/ml-documentation.md`

**Советы:** Ablation отделяет работу от удачи · Фикс без прогона — лотерея перед демо · Худший кейс на демо вылезет обязательно · Воспроизводимость метрик — часть результата

### DELIVERY — Система держит удар

Отвечает за то, что система переживёт нагрузку, отказ зависимости и Demo Day — и что версию можно зафиксировать и воспроизвести.

#### Шаг 1. Нагрузочное тестирование (4–5 часов)

_Демо-день — это пиковая нагрузка; лучше узнать предел заранее._

- Профиль нагрузки по сценариям UC
- Предел системы найден и записан
- Узкие места — с планом или обоснованием «ок»

**Сдаёшь:** Отчёт нагрузочного [документ] → `docs/load-testing.md`

#### Шаг 2. Отказоустойчивость (4–5 часов)

_LLM-провайдер упадёт в самый неподходящий момент._

- Поведение при отказе модели/БД — штатное, не 500
- Деградация по ADR отрабатывает
- Таймауты и ретраи настроены

**Сдаёшь:** Сценарии отказов [документ] → `docs/failure-scenarios.md`

#### Шаг 3. Фиксация версии (2–3 часа)

_Demo Day показывают зафиксированную версию, а не «главную ветку сейчас»._

- Версии зависимостей и моделей зафиксированы
- Релизный тег, воспроизводимая сборка

**Сдаёшь:** Релизная версия [конфиг] → `git tag + lockfiles`

#### Шаг 4. Стабильность прода (2–3 часа)

_Неделя стабильного аптайма — лучший аргумент на демо._

- Мониторинг чист: без красных алертов
- Аптайм и латентность за период — в цифрах

**Сдаёшь:** Отчёт стабильности [документ] → `docs/uptime-report.md`

**Советы:** Предел ищут до того, как в него упрутся · Отказ зависимости — штатная ситуация · Тег дешевле воспоминаний «какая версия работала» · Зелёный дашборд — слайд сам по себе

### QUALITY & SAFETY — Финальный вердикт качества — центр этой лабы

Хозяин спринта: сводит качество и безопасность в один вердикт — почему этому продукту можно верить.

#### Шаг 1. Финальный отчёт качества (5–6 часов)

_Все прогоны семестра сходятся в один документ._

- Финальные evals против критериев успеха из лабы 1
- Динамика метрик за семестр — графиком
- Известные ограничения — честным списком

**Сдаёшь:** Отчёт качества [документ] → `docs/quality/final-quality-report.md`

#### Шаг 2. Финальный отчёт безопасности (4–5 часов)

_Перед публичным демо продукт атакуют свои — чтобы не атаковали чужие._

- Повторный LLAMATOR-прогон после фиксов
- Закрытые и оставшиеся дыры — с оценкой риска
- Инъекции с Demo Day-сценариев — отбиты

**Сдаёшь:** Отчёт безопасности [документ] → `docs/quality/final-security-report.md`

#### Шаг 3. Регрессия на релизе (2–3 часа)

_Вердикт выносится зафиксированной версии, а не движущейся цели._

- Полный прогон на релизном теге
- Quality-gates зелёные на релизе

**Сдаёшь:** Прогон на релизе [код] → `tests/evals/ (на теге)`

#### Шаг 4. Вклад в «почему нам можно верить» (2–3 часа)

_Блок доверия на Demo Day собирается из фактов этой лабы._

- 3–5 фактов с цифрами для презентации
- Скрин дашборда и прогона для слайдов

**Сдаёшь:** Факты доверия для демо [документ] → `docs/quality/trust-facts.md`

**Советы:** Ограничение, названное самим, — сила; найденное залом — провал · Красная команда своих — до, а не после демо · Вердикт — по релизу, не по main · Факт с цифрой убедительнее прилагательного

## Definition of Done

Те же критерии видит автопроверка. Лаба сдана, когда выполнены все группы.

### Качество

- [ ] Финальные evals прогнаны на релизном теге против критериев успеха
- [ ] Отчёт качества содержит динамику за семестр и список ограничений
- [ ] Отчёт безопасности: повторный LLAMATOR, риски оценены
- [ ] Quality-gates зелёные на релизе

### Надёжность

- [ ] Нагрузочное проведено, предел системы записан
- [ ] Отказ модели и БД обрабатывается штатно
- [ ] Релизный тег собирается воспроизводимо
- [ ] Аптайм и латентность за период — в отчёте

### Продукт

- [ ] North Star измерена записанным способом и сравнена с целью
- [ ] Каждая боль из PRD: закрыта / частично / нет — с примером
- [ ] План доработок приоритизирован к демо
- [ ] Нарратив Demo Day опирается на цифры спринта

## Чек-лист перед PR

### Доказательства собраны

- [ ] North Star: факт против цели записан
- [ ] Финальные evals прогнаны на теге
- [ ] Ablation показывает, что дало прирост
- [ ] Отчёты качества и безопасности готовы
- [ ] Нагрузочное и отказы — задокументированы
- [ ] Факты доверия переданы в презентацию

### К демо готовы

- [ ] Релизный тег зафиксирован
- [ ] Прод стабилен, дашборд зелёный
- [ ] План доработок — только влияющее на демо
- [ ] Нарратив согласован командой
- [ ] Известные ограничения сформулированы
- [ ] Демо-сценарий отбит от инъекций

## Материалы к лабе

- [LANGFUSE](/materials/observability/langfuse) — Качество на реальном трафике
- [МУЛЬТИАГЕНТНОСТЬ](/materials/architecture/multi-agent) — Принципы и HITL-точки
- [ОЦЕНИВАНИЕ](/materials/labs/grading-system) — Как считаются баллы
- [ВСЕ МАТЕРИАЛЫ](/materials) — База материалов курса

---

_Спринт доказательств: к его концу у команды есть цифры на каждый вопрос — достигли ли целей, где предел системы и почему продукту можно верить._

Человеческая версия: /labs/lab5