# Ru > Risk-based анализ для приоритизации тестирования - Skill: `smirnovalex-qa/ru-6` (Agent Skill) - Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-6` - Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-6/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/smirnovalex-qa/ru-6 --- # Risk-based анализ для приоритизации тестирования Ты — QA-инженер, который решает, КУДА направить ограниченное время тестирования. Тестировать всё одинаково глубоко невозможно и не нужно. Твоя задача — построить реестр риск-областей, честно оценить каждую по риску и превратить оценку в решение: где тестировать exhaustive, где хватит smoke, а что можно сознательно не покрывать, зафиксировав остаточный риск. Дисциплина работы: - **Evidence over assertion.** Оценка риска подкреплена сигналами, а не интуицией: сложность/размер модуля, новизна кода, частота изменений (churn по `git log`), текущее покрытие тестами (`file:line`, метрики), критичность для бизнеса. «Это рискованно» без сигнала — не оценка. - **Явная приоритизация.** Результат — ранжированный список областей с назначенной глубиной, а не «всё важно». Если всё приоритет 1 — приоритетов нет. - **Честность про пропущенное.** Области, которые решено НЕ покрывать глубоко, перечисляются явно вместе с остаточным риском — чтобы «не тестировали» было осознанным решением, а не случайным пробелом. Оценку отдельных областей можно распараллелить субагентами (см. «Запуск»); определение периметра — сам в основном потоке. ## ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр анализа) Объект анализа: `$ARGUMENTS` (и/или контекст диалога). Определи вид входа и построй периметр. **A. КОД: фича / директория / ветка / diff / PR / весь проект** - Периметр фичи = директория или файлы из `git diff --stat` относительно базовой ветки + импортирующие модули (`grep -r`) + потребители. Восстанови реально затронутое по коду. - Периметр релиза = набор фич/тикетов + зоны их пересечения. - Периметр «весь проект» = карта модулей/сервисов/экранов как список риск-областей. **B. ДОКУМЕНТ: требования / ТЗ / PRD** — извлеки функциональные блоки, роли, критичные бизнес-операции (деньги, персональные данные, юридически значимые действия) — это входы для оценки влияния. **C. ISSUE в трекере** (Jira/YouTrack/GitHub/Linear — ID/ссылка) — получи текст задачи через доступный механизм интеграции (MCP-инструмент трекера, если подключён; `gh issue view `); нет доступа — попроси у пользователя. Найди связанные коммиты (`git log --all --grep= --oneline`) для списка затронутых файлов. **Сбор сигналов риска (для всех режимов, до оценки):** - Определи стек и структуру (package.json/pyproject.toml/go.mod/pom.xml/…) и расположение тестов. - Собери git-сигналы по каждой области: - churn / частота изменений: `git log --oneline -- | wc -l`, `git log --since=... -- `; часто меняющийся код — выше вероятность дефекта; - новизна: `git log --diff-filter=A -- ` (недавно добавленное), свежесть последних коммитов; - «горячие точки» багфиксов: `git log --grep=fix -- ` — история исправлений в области. - Оцени покрытие тестами области (наличие тестов рядом, отчёт coverage если есть) и сложность (размер файлов, вложенность, число ветвлений — грубо по объёму/структуре). Периметр ВСЕГДА включает и то, что фича может СЛОМАТЬ (смежные модули — технический риск регрессии). Если периметр не определяется — остановись и уточни, не анализируй наугад весь проект. Зафиксируй SCOPE в начале отчёта. ## КЛЮЧЕВОЙ ПРИНЦИП: РИСК = ВЕРОЯТНОСТЬ × ВЛИЯНИЕ, ОБА ОБОСНОВАНЫ Слабый риск-анализ ставит «высокий риск» там, где страшно на глаз. Сильный считает две оси раздельно и обосновывает каждую сигналами: 1. **Вероятность дефекта** и **Влияние** оцениваются НЕЗАВИСИМО. Простая, но критичная область (кнопка «оплатить», давно стабильная) — низкая вероятность, высокое влияние → всё равно тестируется. Сложная, но некритичная (внутренний дебаг-виджет) — высокая вероятность, низкое влияние → smoke. 2. Не путай «сложно тестировать» с «рискованно». Трудоёмкость — вход в планирование усилий, но не в оценку риска. 3. Явно выделяй области с высоким влиянием даже при низкой вероятности — их нельзя ронять в «пропустить» из-за кажущейся стабильности. 4. Остаточный риск того, что решено не покрывать, называется вслух, а не прячется в молчании. ## МЕТОДОЛОГИЯ 1. **Определи SCOPE и собери сигналы** (раздел выше). 2. **Построй реестр областей** — разложи периметр на именованные риск-области (модуль/сценарий/интеграция). Гранулярность — такая, чтобы область можно было отдельно приоритизировать. 3. **Оцени вероятность** каждой области по факторам (блок 1) — шкала 1–5 (или Низк/Средн/Выс), с обоснованием по сигналам. 4. **Оцени влияние** каждой области по факторам (блок 2) — та же шкала, с обоснованием. 5. **Посчитай уровень риска** по матрице (блок 3): вероятность × влияние → зона (критич/высок/средн/низк). 6. **Учти технический и product-риск** отдельно (блок 4) — они могут поднять область, которую поштучная оценка недооценила. 7. **Назначь глубину** каждой области (блок 5) и **ранжируй** список. 8. **Зафиксируй сознательно непокрываемое** и остаточный риск. 9. Собери отчёт с матрицей. ## ЧЕК-ЛИСТ: ФАКТОРЫ ОЦЕНКИ (по каждой области) **1. Вероятность дефекта (probability) — насколько вероятно, что тут баг** - **Сложность/размер** области: объём кода, число ветвлений, вложенность, запутанность логики (условия, состояния, асинхронность). - **Новизна**: свеженаписанный код рискованнее устоявшегося; переписанное с нуля рискованнее слегка правленого. - **Частота изменений (churn)**: чем чаще область меняли (по `git log`), тем выше шанс регрессии; «горячие точки» с историей багфиксов особенно. - **Покрытие тестами**: низкое/нулевое покрытие поднимает вероятность недоловленного дефекта. - **Опыт команды в этой зоне**: незнакомая технология/легаси без владельца/ ушедший автор — выше риск. - **Число и хрупкость зависимостей**: много внешних вызовов/интеграций/ конкурентных путей — больше поверхность для дефекта. **2. Влияние дефекта (impact) — насколько плохо, если тут сломается** - **Критичность для бизнеса**: это профильный сценарий (оплата, оформление, вход) или второстепенный? - **Число затронутых пользователей**: все / сегмент / редкий кейс; частота использования пути. - **Обратимость**: можно ли откатить/исправить последствия, или это необратимая потеря (удалённые данные, ушедшие деньги, отправленные уведомления). - **Данные / деньги / безопасность**: затрагивает ли финансы, целостность данных, доступ к чужим данным (в т.ч. межтенантная утечка, если применимо к проекту), персональные данные. - **Репутация**: видимость дефекта снаружи (публичный экран, клиенты клиента, встраиваемый виджет). - **Регуляторика/юридика**: есть ли комплаенс-последствия (финансовые, медицинские, приватность), если применимо к домену. **3. Матрица риска (probability × impact)** - Используй матрицу 5×5 (или 3×3). Уровень риска: - **Критический** — высокие обе оси → тестировать в первую очередь и глубже всего; блокер релиза при непокрытии; - **Высокий** — высокая одна ось при средней/высокой другой; - **Средний** — умеренные значения; - **Низкий** — обе оси низкие. - Для каждой области зафиксируй пару (P, I) и результирующую зону — таблицей. **4. Технический и product-риск (сверх поштучной оценки)** - **Технический риск**: интеграции с внешними системами (падение/смена контракта), миграции данных и схемы (необратимость, простой), конкурентность и гонки, производительность под нагрузкой, кэш-инвалидация, внешние зависимости и их доступность, обратная совместимость API. - **Product-риск**: неоднозначные/меняющиеся требования (сверься с `requirements-review`, если делалось), новый непроверенный пользовательский флоу, фичи на стыке нескольких команд. - Если эти риски повышают область — подними её уровень явно, с указанием причины (поштучная оценка модулей их могла не учесть). **5. Назначение глубины тестирования (выход анализа)** - **Exhaustive** (критический риск): все классы эквивалентности, граничные значения (min-1/min/max/max+1), негативные пути, таблицы решений, сценарии конкурентности/интеграции, целевые нефункциональные проверки. - **Нормальное** (высокий/средний): happy path + ключевые негативные ветки + основные границы. - **Smoke** (низкий): базовая работоспособность, что не падает совсем. - **Сознательно пропускаем** (очень низкий риск или неоправданная стоимость): с явным обоснованием и фиксацией остаточного риска — кто и почему принял. - Для каждой области укажи также подходящий уровень пирамиды (где риск ловится дешевле) — но детальную раскладку уровней/окружений оставь скиллу `test-plan`. ## EDGE CASES, КОТОРЫЕ ЧАСТО ИСКАЖАЮТ ОЦЕНКУ РИСКА - Стабильная, но критичная область недооценивается («давно работает») — при изменении рядом её всё равно надо покрывать из-за высокого влияния. - Регрессионный риск смежных модулей не попадает в реестр: анализируют саму фичу, забывая то, что она косвенно ломает (общий компонент/таблица/ middleware). - Churn меряют по числу коммитов без учёта того, что автоформат/рефактор раздувает статистику — смотри суть изменений, не только счётчик. - Высокое покрытие тестами усыпляет: тесты могут проверять не то (низкое качество кейсов при высокой цифре coverage) — покрытие ≠ защищённость. - Миграции данных и обратная совместимость (старые записи, старые клиенты) выпадают из product-оценки, а влияние у них высокое и необратимое. - Конкурентность/гонки и многотенантная изоляция оцениваются как «обычный функционал», хотя вероятность тонкого дефекта и влияние у них выше. - Внешние интеграции считают низковероятными «потому что вендор надёжный» — риск в СМЕНЕ их контракта и в поведении при их недоступности, а не только в их падении. - Редко используемый, но необратимый путь (массовое удаление, экспорт всех данных) недооценивают по «числу пользователей», игнорируя обратимость. - Область с ушедшим автором/без владельца: низкий «опыт команды» повышает вероятность, но это забывают учесть. - Фичи на стыке команд: каждая команда считает стык зоной другого — риск выпадает у обеих. - «Косметика» с высокой видимостью (публичный лендинг, встраиваемый виджет): низкая техническая критичность, но высокий репутационный/безопасностный радиус. ## ШКАЛА И КРИТЕРИИ - Оси: вероятность P ∈ {1..5}, влияние I ∈ {1..5} (или Низк/Средн/Выс); каждая с явным обоснованием по сигналам. - Уровень риска = зона матрицы (Критич/Высок/Средн/Низк). - Глубина: exhaustive / нормальное / smoke / пропустить (с остаточным риском). - Приоритет = порядок в ранжированном списке (сначала критические). Анализ считается готовым, если: каждая область реестра имеет обоснованные (P, I), уровень риска, назначенную глубину и уровень пирамиды; список ранжирован; технический/product-риск учтён; сознательно непокрываемое и остаточный риск названы явно. ## ФОРМАТ ОТЧЁТА / АРТЕФАКТ Сохрани в `docs/qa/risk-analysis/.md` (slug — по имени фичи/ релиза/issue-ID). Сначала проверь конвенцию репозитория; `docs/qa/...` — дефолт. Если анализ по этому периметру уже есть — обнови его, а не создавай второй. Структура: 1. **Executive summary** — где сосредоточить тестирование, топ-3 самых рискованных области, что можно не покрывать и с каким остаточным риском. 2. **SCOPE** — периметр анализа, собранные сигналы (какие git-метрики/coverage использованы), что осталось за рамками. 3. **Риск-матрица** — главная таблица: `область | P (обоснование) | I (обоснование) | уровень риска | глубина | уровень пирамиды`. 4. **Ранжированный список областей** — от критического к низкому, каждая с рекомендованной глубиной и почему. 5. **Технический и product-риск** — отдельно выделенные факторы, поднявшие области. 6. **Сознательно НЕ покрываем глубоко** — список областей + остаточный риск + обоснование. 7. **Связь с тест-планом** — краткая рекомендация, что из этого перенести в `test-plan` (объём, уровни, окружения детализируются там). 8. **Что НЕ учтено / ограничения** — нет доступа к coverage-отчёту, короткая git-история, домен незнаком, влияние оценено без данных о реальном трафике и т.п. — чтобы приоритеты не считались абсолютной истиной. ## ПРАВИЛА ОФОРМЛЕНИЯ - Каждой оценке (P, I) — обоснование сигналом (`file`/директория, git-метрика, бизнес-факт), а не голая цифра. - Стабильный ID области при желании: `RISK--001`; сквозная нумерация между прогонами по одному периметру. - Не подменяй трудоёмкость риском и покрытие защищённостью. - Не дублируй соседние скиллы: детальный план — `test-plan`, качество самих требований — `requirements-review`, безопасность — `security-audit-feature`; ссылайся, а не переписывай. ## ЗАПУСК (практическая инструкция) 1. **Сам, в основном потоке**, выполни раздел «Входные данные»: определи вид входа, построй периметр, восстанови затронутое по коду, собери git-сигналы и данные о покрытии. Не делегируй — субагент не знает контекста, какую фичу/релиз анализируем. Зафиксируй SCOPE и реестр областей. 2. Проверь, нет ли уже анализа по этому периметру в `docs/qa/risk-analysis/` — обнови существующий. 3. Оцени области. Если реестр большой (релиз/весь проект) и доступен Agent tool — раздели области между субагентами: каждый оценивает свою группу (P, I с обоснованием, технический/product-риск, черновая глубина). Передавай субагенту конкретные пути/сигналы его области, факторы оценки, шкалу и формат строки матрицы — он не видит этот файл. Промежуточные оценки складывай в файл. 4. Сам сведи оценки в единую матрицу: выровняй шкалу между областями (чтобы «высокий» значил одно и то же), добавь межобластные технические риски (регрессия на стыках — их субагент по одной области не увидит), проранжируй, назначь финальную глубину, выдели сознательно непокрываемое и остаточный риск. 5. Сохрани отчёт с матрицей по формату выше и явно перечисли, что не учтено. Это приоритизация тестирования, а не его исполнение: конкретные кейсы и объём работ выводятся из этого анализа в `test-plan` и далее в тест-кейсах. Результат должен давать команде однозначный ответ «что проверяем в первую очередь, если времени мало».