Модуль 9. Тестирование и приемка с участием BA
Зачем BA в тестировании
Цель: выпустить работающую фичу, которая решает исходную бизнес-проблему. QA отвечает за дефекты и тех.качество, BA — за смысл (метрики, правила, сценарии) и приемку по целям BRD/SRS/NFR.
BA делает:
- Пишет приемочные сценарии (Given/When/Then) + негативные кейсы.
- Готовит «золотые» выборки/эталоны (reference) для сверки метрик.
- Проверяет NFR (отклик, свежесть, RLS) вместе с командой.
- Организует UAT: план, участники, дефект-трекинг, критерии выхода, sign-off.
- После запуска — мониторинг метрик эффекта и, при необходимости, эксперименты (A/B).
Тест-дизайн на уровне BA: что проверять всегда
«Пирамида» для BI/DWH (что важно BA)
- Методология и данные: формулы, исключения, гранулярность, историчность.
- Сценарии пользователя: фильтры, drill-down, экспорты, роль-бэйзд доступ.
- НФТ/NFR: отклик p95, свежесть, стабильность фильтров, аудит, DQ-реакции.
Heuristics (шпаргалка BA)
- Фильтры × Комбинации: дата×регион×канал, пустых таблиц быть не должно.
- Totals ≡ Сумме: итоги равны сумме строк после фильтров/RLS.
- Деление на ноль: GM% при нулевой выручке → «—»/0; не NaN/Inf.
- Края периодов: конец месяца/года, смена лет/фискальных периодов.
- Историчность: SKU сменил категорию — статистика прошлого не «поехала».
- Возвраты/сторно: дата отражения и поведение KPI.
- Роли: «Регион X» не видит Y, итог у CEO = сумме по всем.
- DQ-срывы: баннер «черновик», блок экспорта, алерт.
- Перф: p95 на «худших» выборках, «холодный» и «горячий» кэш.
Приемочные сценарии (Acceptance) — как писать
Шаблон Gherkin:
Как [роль] я хочу [действие], чтобы [ценность].
Given контекст / When действие / Then ожидаемый результат (измеримый).
Пример (GM% дашборд):
-
AC-01 Формула и эталон
Given период Май-2025 и канал «Онлайн», When открываю дашборд, Then GM% совпадает с эталоном GM_reference_May.xlsx по 10 SKU (допуск ±0.2 п.п.). -
AC-02 Фильтры совместно
Given фильтры «Регион X» + «Категория Y», When применяю их вместе, Then таблица непуста, итоги соответствуют сумме строк. -
AC-03 RLS
Given пользователь роли «Регион X», When открывает страницу, Then видит только X; при попытке экспорта — выгружается только X. -
AC-04 Неполные данные
Given полнота логистики <98%, When открываю дашборд, Then отображается баннер «черновик» и экспорт заблокирован. -
AC-05 Перфоманс
Given 12 месяцев истории и 20 одновременных пользователей, When открываю «Обзор», Then p95 ≤ 5 сек (APM/BI-телеметрия). -
AC-06 Drill-down
Given топ-категория «Beverages», When проваливаюсь до SKU, Then список отсортирован по GM% убыв., суммы сходятся. -
AC-07 Пограничные даты
Given 31.12.2025 → 01.01.2026, When переключаю период, Then GM% не «ломается», курс/НДС применены по правилам. -
AC-08 Ошибочные данные
Given отрицательные продажи есть, When считаю GM%, Then такие строки исключены и помечены в DQ-виджете.
«Золотые» выборки и эталоны
Reference-наборы — маленькие, но проверенные таблицы/SQL-снапшоты (10–20 SKU/магазинов, 1 период).
BA обеспечивает: источник, формулу, допуск, версию методологии.
Совет: держите 2 набора — «обычный» и «адверсариальный» (возвраты, нули, край периода, промо). Храните рядом с SRS и обновляйте при смене методики (change-log).
План UAT: роли, шаги, выходной документ
Участники: BA (ведёт), PO/заказчик (решения), Key Users, QA, Dev/BI, Data Steward/Owner, Security (при RLS/ПДн).
Артефакты: UAT Plan, тест-кейсы, график, протокол дефектов, exit-criteria, sign-off.
Шаги:
- Kick-off: цели, критерии успеха, роли, календарь.
- Демо/обучение: короткая сессия перед тестом.
- Сценарное тестирование: по AC + негативные кейсы; сбор фактов (скрин/CSV/лог).
- Дефект-треаж: Severity/Priority, SLA исправлений, кто фиксит.
- Ретест/регресс: на откорректированных сборках.
- Exit-review: сверка с критериями выхода.
- Sign-off: акт приемки или список блокеров и план.
Критерии выхода (пример):
- 100% Must-AC пройдены; Should ≥ 90% (остальное — CR/Next).
- p95 ≤ 5 сек, Freshness ≥ 98%, RLS-тесты «зеленые».
- DQ-правила на месте, алерты работают.
- Документация и «паспорт дашборда» заполнены.
Чек-лист приемки (BI/DWH)
- Формулы KPI = словарю (допуски соблюдены).
- Фильтры/даты/сортировки корректны, пустот нет без объяснения.
- Итоги = сумме строк (учитывая RLS).
- Drill-down ↔ roll-up консистентны.
- НФТ: p95 ≤ 5 сек; экспорт ≤ 30 сек; Freshness ≥ целевого; uptime в окне теста.
- RLS/маскирование ПДн; попытки обхода блокируются.
- DQ-виджет, баннер «черновик», алерты на пороги A/B.
- Логи/аудит событий включены; trace-id видны.
- Паспорт: цель, владелец, версия методики, дата свежести, источники, ограничения.
- Руководство пользователя/FAQ и план обучения готовы.
NFR-приемка: как BA смотрит на «нефункционал»
- Перфоманс: заранее определённый профиль «тяжёлых» запросов; измеряем APM/SQL-логом; отчёт p50/p95/p99.
- Свежесть: индикатор времени данных; тест с искусственной задержкой.
- Доступность: плановый DR-drill (переключение, RTO/RPO).
- Безопасность: роль-наборы, отрицательные тесты (доступ «соседнего» региона, выгрузка ПДн).
- Интеграции: деградация источника → поведение «fallback/черновик».
Пост-запуск: проверка метрик и эффект
Value Realization:
- Принятие: MAU/WAU, глубина сессий, % пользователей, завершивших сценарий.
- Операционные: цикл закрытия (3→1 день), доля ошибок DQ, доля «черновиков».
- Финансовый эффект: рост GM%/экономия FTE/снижение OOS.
- Стабильность: Freshness, перфоманс p95, инциденты.
Паспорт дашборда дополняем блоком «Эффект/метрики после запуска» + релиз-ноты изменений методологии.
A/B (и другие эксперименты): когда уместно и как не промахнуться
Когда уместно: новый UX/виджеты/алерты; алгоритмы ранжирования; рекомендации; правила отбора SKU-неров; коммуникации в BI (баннеры, подсказки).
Когда спорно: агрегированные управленческие отчёты, где изменяется поведение менеджеров в целом — там лучше квази-эксперименты.
Принципы:
- Гипотеза: «Если показывать список SKU с падением GM% >1 п.п., то скорость реакции сократится на 1 день».
- Метрики: целевая (скорость реакции), guardrails (GM% не падает, MAU не падает).
- Дизайн: рандомизация (по пользователям/магазинам), размер выборки, горизонт, power (обычно ≥80%).
- Ramp-up: 10%→50%→100% при отсутствии вреда.
- Статистика: фиксированное окно/или корректная последовательная проверка; не «смотреть каждый час» без поправок.
- Этика/регуляторика: не ухудшать опыт/безопасность, не нарушать ПДн.
Альтернативы A/B:
- До/после (сезонные поправки), difference-in-differences (контрольная группа), перекрёстные запуски (rollout по регионам).
Практика: набор acceptance-кейсов (минимум 12)
- GM% свертка: эталонное совпадение по 10 SKU (±0.2 п.п.).
- Период и календарь: декабрь→январь, фискальный год.
- Промо-флаг: promo vs non-promo, расхождение в допуске.
- Возвраты: возвраты вне периода — корректировка текущего.
- Фильтры в комбинации: дата×регион×канал×категория.
- Drill-down: канал→категория→SKU; roll-up консистентен.
- RLS: роль «Регион X», экспорт — только X.
- DQ-порог: при полноте <98% — баннер и блок экспорта.
- Перфоманс: p95 ≤ 5 сек, «холодный/горячий» кэш.
- Экспорт: формат, размер, тайм-аут ≤ 30 сек.
- Ошибочные данные: отрицательные продажи/нулевая выручка — корректное поведение.
- Аудит: запись в журнал «изменена методология/формула», trace-id.
Риски и как их снять
|
Риск |
Симптом |
Профилактика/Решение |
|---|---|---|
|
«Сдвиг ворот» на UAT |
Новые требования «на финише» |
Замороженный SRS/словарь на релиз + CR-процесс |
|
Нереалистичные тест-данные |
На проде «всё поехало» |
PERF-UAT ≈ прод, «адверсариальные» эталоны, backfill |
|
Метрики «не бьются» |
Споры с финансами |
Эталонные файлы, допуски, владелец метрики, версия методологии |
|
RLS ломает суммы |
Разные итоги у ролей |
Роль-тесты, «итоговые» витрины под RLS, юнит-калькуляции в семантике |
|
DQ-срывы без реакции |
Пользователи принимают неверные решения |
Баннер/блок экспорта/алерты, регламенты и обучение |
|
Перф. деградация |
>5 сек p95 |
Агрегаты/экстракты, пред-фильтры по умолчанию, индексы, профилирование |
|
Отсутствует sign-off |
«Кто принял?» |
Единый шаблон акта, PO/владелец метрики подписывает |
Теория — «ровно сколько нужно»
- Верификация vs Валидизация: «правильно реализовали» vs «правильную вещь сделали». BA закрывает обе.
- Traceability: BRD-цель → SRS-пункт → Story/Use Case → AC/Test → UAT протокол → эффект.
- Приёмка по гипотезам: фича считается принятой, если достигнуты ранние (lead) метрики (MAU, время реакции) и итоговые (lag) — по плану мониторинга.
- Надёжность измерений: фиксируйте источник метрик (APM/BI-телеметрия/логи ETL), период агрегации, допуски.
- Слепые зоны: Симпсонов парадокс (итоги растут, сегмент падает) — проверяйте ключевые срезы.
Шаблоны (скопируйте в Confluence/Jira)
UAT Plan (каркас):
- Цель/Scope/Out of Scope
- Участники/Роли/Контакты
- Расписание/Окна
- Список кейсов (ID, приоритет, владелец)
- Критерии выхода (NFR/AC)
- Материалы: эталоны, данные, доступы
- Формат отчётности и triage SLA
Тест-кейс (пример строки):
- ID, Название, Приоритет
- Предусловия
- Шаги
- Ожидаемо (с числом/допуском)
- Фактический результат
- Статус, артефакты (скрин/CSV/лог), версия методологии
Протокол дефектов:
- ID, Описание, Шаги, Severity (Blocker/Critical/Major/Minor), Priority, Компонент, Ответственный, ETA, Статус, Комментарии
Акт приёмки (sign-off):
- Объект, Версии (продукт/методология), Дата
- Результат UAT (пройдено/не пройдено), список отклонений/CR
- Решение PO/владельца метрики, подписи
Чек-лист пост-запуска:
- Мониторинг p95/Freshness/Errors
- Дашборд «Здоровье данных» зелёный
- MAU/обучение/FAQ опубл.
- Release notes и паспорт обновлены
Практика (что сдать по итогу модуля)
- Набор acceptance-кейсов (12+) по вашему дашборду/витрине (с AC и допусками).
- UAT Plan (1–2 стр.): участники, расписание, критерии выхода, triage SLA.
- Чек-лист приёмки (ваша адаптация) на 15–20 пунктов.
- Акт приёмки (шаблон заполненный) и короткий отчёт пост-запуска (MAU/p95/Freshness + 1–2 метрики эффекта).
Вы переводите «готово» из субъективного в измеримое: AC с эталонами и допусками, UAT с критериями выхода, NFR-приемка, паспорт дашборда и мониторинг эффекта. Если это всё есть, релиз либо обоснованно принимается, либо честно возвращается с понятными доработками — и бизнес понимает почему. Если хотите, соберу ваши реальные кейсы в UAT-пакет (кейсы, данные, чек-лист, акт) и «проводник» по пост-запускным метрикам.
