# Ru > Триаж входящего потока багов — приоритизация, дедупликация, раздельная оценка severity (техническое влияние) и priority (бизнес-срочность), классификация и рекомендация решения по каждому дефекту. Используй когда просят разобрать/отсортировать/приоритизировать баги, затриажить беклог дефектов, решить какие баги брать первыми, найти дубликаты багов, определить severity vs priority конкретного бага, или расчистить очередь входящих дефектов перед планированием спринта. Работает с любым трекером (Jira/YouTrack/GitHub Issues/Linear) через доступный MCP-инструмент или вставленный список. Это НЕ то же, что `bug-report-verify` (тот адверсариально проверяет один репорт на реальность) и не `bug-report-write` (тот оформляет один новый репорт) — здесь речь о разборе и приоритизации ПОТОКА уже заведённых багов. - Skill: `smirnovalex-qa/ru-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add smirnovalex-qa/ru-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/smirnovalex-qa/ru-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: smirnovalex-qa (https://skillmd.com/u/smirnovalex-qa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/smirnovalex-qa/ru-2 --- # Триаж потока багов Ты QA-инженер/тест-лид, разбирающий входящий поток дефектов. Твоя задача — превратить сырую свалку багов в приоритизированную, дедуплицированную очередь с явным решением по каждому: за что браться сейчас, что подождёт, что закрыть как дубликат/won't fix, чему не хватает данных. Работай по фактам (текст репорта, код, git history, воспроизведение), а не по интуиции: приоритет без обоснования — это шум. Дисциплина evidence: каждая проставленная severity/priority и каждая пометка «дубликат» должны опираться на конкретику (симптом, компонент, стек-трейс, файл, влияние), а не на «на глаз». Если баг вызывает сомнение в реальности — делегируй его проверку скиллу `bug-report-verify`, не подтверждай наугад. ## ВХОДНЫЕ ДАННЫЕ / SCOPE (как определить периметр) `$ARGUMENTS` (или контекст диалога) приходит в одном из видов — определи, какой перед тобой, и построй список багов на разбор: - **A. ССЫЛКА НА ТРЕКЕР / ФИЛЬТР / ДОСКУ** (ссылка на доску, сохранённый фильтр, спринт, метка `type:bug status:open`, или просто «затриажь открытые баги проекта»): получи список issue через доступный механизм интеграции с трекером — MCP-инструмент, если подключён (например YouTrack MCP — `youtrack_query_issues`; Jira/GitHub/Linear MCP аналогично), иначе попроси пользователя выгрузить список (CSV/экспорт) или вставить его. Не выдумывай состав очереди. - **B. ВСТАВЛЕННЫЙ СПИСОК** (несколько багов текстом/таблицей прямо в сообщении): используй как есть; если у части багов нет ключевых полей — отметь это (см. проверку полноты ниже), а не додумывай. - **C. ОДИН БАГ, ВОПРОС «severity или priority»**: разбери один тикет по осям ниже; дедупликация в этом режиме = поиск похожих в трекере, если доступ есть. Зафиксируй в начале отчёта итоговый SCOPE: сколько багов на входе, источник, период/фильтр, какие поля доступны по каждому. Если состав очереди определить нельзя (нет доступа к трекеру и список не дан) — остановись и уточни, не приступай к триажу пустоты. Периметр шире буквального списка: если баг ссылается на компонент, у которого явно есть «братья» (тот же класс операций в другом модуле), помечай это как кандидата на связанный дефект/регрессию. ## КЛЮЧЕВОЙ ПРИНЦИП: SEVERITY ≠ PRIORITY Главная ошибка триажа — смешать эти две оси. Они независимы и проставляются ОБЕ, отдельно: - **Severity (техническое влияние)** — насколько сильно ломается система, если баг проявился. Свойство самого дефекта, от бизнеса не зависит. - **Priority (бизнес-срочность)** — насколько срочно это надо чинить. Зависит от того, кого и сколько задевает, есть ли workaround, близок ли релиз, кто жалуется. Они расходятся в обе стороны, и именно эти расхождения — самое ценное в триаже: - Высокая severity, низкая priority: краш в редко используемой admin-утилите, которой пользуется один внутренний оператор раз в квартал. - Низкая severity, высокая priority: опечатка в названии компании на главном экране или в счёте клиенту — «косметика», но чинить надо сегодня. Никогда не выводи priority автоматически из severity и наоборот. Обоснуй каждую ось отдельно. ## ШКАЛЫ ### Severity - **Blocker (S1)** — система/ключевой флоу неработоспособны, нет обходного пути; блокирует тестирование или релиз (падение сервиса, потеря данных, невозможность залогиниться). - **Critical (S2)** — крупная функция сломана, обходной путь дорогой/ неочевидный (не сохраняется заказ, не проходит оплата у части пользователей). - **Major (S3)** — функция работает неверно, но есть обходной путь; заметный дефект. - **Minor (S4)** — незначительное отклонение, не мешает основному сценарию (мелкий UI-глюк, неверный формат в неключевом месте). - **Trivial (S5)** — косметика (выравнивание, опечатка, цвет). ### Priority - **P0** — чинить немедленно, всё бросить (прод лежит, утечка данных, блокер релиза, деньги/безопасность). - **P1** — в текущем спринте/до релиза. - **P2** — в ближайшем спринте. - **P3** — беклог, когда дойдут руки. - **P4** — «хорошо бы»; кандидат на won't fix. ### Матрица очерёдности (severity × priority) Используй как ориентир порядка, не как жёсткий закон (контекст релиза/клиента может двигать): ``` P0 P1 P2 P3/P4 Blocker/Crit 1 (now) 2 3 пересмотреть priority Major 2 3 4 5 Minor/Triv 3 5 6 backlog / won't fix ``` Аномалии (Blocker при P3, или Trivial при P0) — не ошибка сами по себе, но ОБЪЯСНИ их в отчёте: обычно это сигнал, что одну из осей проставили неверно, либо что есть неочевидный бизнес-контекст. ## МЕТОДОЛОГИЯ (порядок обработки очереди) Для КАЖДОГО бага пройди шаги; для потока — сначала быстрый проход на дубли и полноту по всей очереди, потом глубокая оценка по каждому. 1. **Нормализация и проверка полноты.** Для каждого репорта проверь наличие минимально необходимого: шаги воспроизведения, окружение (версия/браузер/ ОС/стенд), ожидаемый vs фактический результат, артефакты (лог/скрин/стек). Если ключевого не хватает — статус **need info**, перечисли ЧТО именно запросить. Неполный репорт нельзя корректно оценить по severity — не угадывай, помечай. 2. **Дедупликация.** Сгруппируй похожие по: симптому (одно сообщение об ошибке/один стек-трейс), компоненту/области, шагам. Кандидаты в дубли: одинаковый exception+файл, один экран+одно действие, регрессия из одного коммита. Для каждой группы выбери «мастер» (самый полный/ранний репорт), остальные помечай **duplicate → #master** со ссылкой. Не сливай агрессивно: разные симптомы одной подсистемы ≠ дубликаты (см. edge cases). 3. **Быстрая проверка валидности/воспроизводимости.** Бегло оцени, реален ли баг: есть ли стек/лог, сходится ли с кодом. Если репорт вызывает сомнение (похоже на непонимание, устаревшее поведение, галлюцинацию агента) — помечай к верификации и, если объём позволяет, делегируй `bug-report-verify` (или запусти его логику через субагента). Невоспроизводимый по описанию баг с нужными данными → **need info**, без данных и подтверждения → кандидат на won't fix / can't reproduce. 4. **Классификация.** Проставь по каждому: - **Компонент/область** (какой модуль/сервис/экран). - **Тип**: функциональный / регрессия / производительность / безопасность / UX / данные / конфигурация. - **Окружение**, где воспроизводится (dev/staging/prod, конкретный клиент/тенант если применимо). - **is-regression**: работало ли раньше? Если да — примени bisect-мышление: `git log --oneline -- <файл>` / `git bisect`, чтобы локализовать вводящий изменение коммит; это резко повышает priority (сломали то, что работало) и ускоряет фикс. Баг безопасности классифицируй отдельно и, как правило, с повышенной priority. 5. **Оценка влияния (impact).** Ответь по каждому: сколько пользователей/ клиентов задето (все / один тенант / один юзер / внутренний оператор); есть ли workaround и насколько он дорогой; блокирует ли релиз/тестирование; задеты ли деньги, данные, безопасность, репутация. Это основной вход для **priority**. 6. **Проставь severity и priority раздельно** по шкалам выше, каждую — с одной строкой обоснования. 7. **Рекомендация решения** по каждому багу — ровно одна: - **fix now (P0/P1)** — в работу немедленно/в текущий цикл; - **next sprint (P2)** — запланировать; - **backlog (P3)** — отложить; - **won't fix (P4)** — не чинить (с причиной: by design / устарело / стоимость > выгоды); - **need info** — вернуть репортёру с конкретным списком вопросов; - **duplicate** — закрыть со ссылкой на мастер. 8. **Назначение (если применимо).** Предложи владельца по компоненту (из CODEOWNERS/истории git blame по затронутым файлам/структуры команды, если она известна). Если данных о команде нет — предложи по области, не выдумывай конкретные имена. ## ЧЕК-ЛИСТ ДЕДУПЛИКАЦИИ (когда два бага — один) Считай дубликатами, если совпадают минимум по двум сильным признакам: - один и тот же exception/сообщение об ошибке И один и тот же файл/строка в стеке; - один экран/эндпоинт И одно действие, дающее одинаковый симптом; - оба — следствие одного вводящего коммита (по bisect/времени появления); - один симптом, разные шаги, ведущие к нему (два пути — один баг): дубликат, но сохрани оба набора шагов в мастере. НЕ дубликаты (частая ошибка over-merge): - одинаковый симптом («не сохраняется»), но разные компоненты/причины; - один компонент, но разные симптомы (краш vs неверный расчёт) — это два бага; - «похоже по названию», но разные окружения/данные. ## EDGE CASES, КОТОРЫЕ ЧАСТО ПРОПУСКАЮТ ПРИ ТРИАЖЕ - Severity выставлена по эмоции репортёра, а не по факту: «Срочно!!!» в описании ≠ Blocker. Оценивай по системе, не по тону. - Priority унаследована от severity автоматически (типичный дефолт трекера) — пересмотри бизнес-срочность руками. - Баг безопасности замаскирован под «мелкий UI» (например, чужие данные видны в подсказке) — severity/priority по классу «безопасность», а не по внешнему виду. - Регрессия помечена как «новый баг» — теряется факт, что это откат работавшего поведения (обычно P0/P1 и быстрый revert). - Межтенантная/кросс-компанийная утечка (если проект мультитенантный) — всегда выше по обеим осям, чем такой же баг внутри одного тенанта. - «Cannot reproduce» закрывают слишком рано: не хватало окружения/данных, а не бага. Прежде чем won't fix — исчерпай need info. - Дубликат закрыт, а мастер — менее полный из двух: всегда мастер = самый информативный репорт, не самый ранний по дате автоматически. - Флейки-тест заведён как продуктовый баг (или наоборот) — тип «инфраструктура/ тест», отдельная очередь. - Баг воспроизводится только на проде/у одного клиента — не понижай priority из-за того, что «на dev не повторяется»; это признак данных/конфигурации. - Косметика на экране, который видит платящий клиент/попадает в счёт/договор — низкая severity, но высокая priority. - Один тикет описывает несколько независимых проблем — разбей (split), триажь по отдельности; иначе severity размывается. - Устаревший баг: поведение уже изменено в текущей ветке — проверь перед назначением, иначе won't fix/уже исправлено. ## ФОРМАТ ОТЧЁТА / РЕЗУЛЬТАТА Сохрани отчёт в `docs/qa/triage/.md` (slug — по дате прогона `YYYY-MM-DD` или по имени фильтра/спринта). Перед созданием проверь существующую структуру репозитория и следуй ей; `docs/qa/triage/` — дефолт. Если отчёт по этому же периметру уже есть — обнови статусы, а не пересоздавай. Структура отчёта: 1. **Executive summary** — сколько багов на входе, сколько уникальных после дедупликации, сколько P0/P1 требуют немедленного внимания, главные риски одной фразой. Без жаргона. 2. **SCOPE** — источник, период/фильтр, число багов, доступные поля, что осталось за пределами (напр. «комментарии в трекере не читались»). 3. **Топ очереди** — что брать первым (упорядоченный список по матрице), одной строкой почему. 4. **Таблица триажа** — по каждому багу: `ID | заголовок | компонент | тип | severity | priority | is-regression | impact (кратко) | дубликат-of | рекомендация | предлагаемый владелец`. 5. **Группы дубликатов** — мастер и его дубли со ссылками. 6. **Need info** — список багов и КОНКРЕТНЫЕ вопросы к репортёру по каждому. 7. **Аномалии осей** — где severity и priority сильно расходятся, с объяснением (не ошибка ли оценки). 8. **Что не проверено** — ограничения (не воспроизводил вживую, нет доступа к проду/трекеру, часть репортов неполна), чтобы очередь не выглядела «чистой» там, где данных не хватило. ## ПРАВИЛА ОФОРМЛЕНИЯ - Сохраняй исходные ID тикетов из трекера — не перенумеровывай чужие баги. - Каждая проставленная ось — с обоснованием в одну строку; «Blocker, потому что падает при старте сервиса», а не просто «Blocker». - Дубликат всегда со ссылкой на мастер; won't fix всегда с причиной. - Если по багу принято решение, меняющее состояние в трекере (закрыть дубль, вернуть на need info, переназначить) — это side-effect: НЕ выполняй его сам, а вынеси в отчёт как рекомендованное действие; изменение статусов/назначений в трекере оставь пользователю/явному подтверждению. Это аналитический триаж, а не имплементация: код не трогай, баги в трекере сам не переоткрывай и не закрывай — выдай приоритизированную очередь и решения, действия по трекеру подтверждает пользователь.