Qa Task Testing

---
name: qa-task-testing
description: "Полный QA-цикл по задаче из трекера: смысл доработки, карта изменений по PR во всех репозиториях, матрица проверок, тест-план на согласование до прогона, прогон на стенде (API, SQL-фикстуры с откатом, очереди, трейсы), баги и тест-кейсы. Используй всегда, когда просят «протестируй задачу», «составь план тестирования», «что проверять», «проверь на стенде», «это баг?», и при любом неожиданном поведении сервиса на стенде. English: QA workflow, test plan from Jira ticket, test matrix, regression."
license: MIT
compatibility: "Нужны доступ к трекеру задач (Jira), вики (Confluence), Git-хостингу (Bitbucket Server, GitHub или GitLab) и тестовому стенду; curl и python3. Опционально: psql или docker, Jaeger, RabbitMQ management, Allure TestOps, MCP-серверы этих систем, база знаний Obsidian."
metadata:
  author: KonstantinVCH
  version: "1.0.0"
  language: ru
---

# Тестирование задачи из трекера — рабочий протокол

Протокол ведёт задачу от тикета до вердикта: понять, зачем доработка, найти весь изменённый код,
составить матрицу проверок, согласовать план с человеком, прогнать на стенде с доказательствами,
откатить данные и оформить результат. Главная ценность — не порядок шагов сам по себе, а уроки,
встроенные в каждый шаг: почти каждое правило появилось после ложного «бага», ложного «в коде нет»
или прогона на негодных данных.

## Настройка под проект

Адреса систем, ключ проекта, стенды, список репозиториев, соглашения команды — в шаблоне
`references/project-config.md`. Заполни его при первом запуске (или найди заполненную копию в базе
знаний проекта). Не заполнен — спроси у человека недостающее, не угадывай адреса и имена сервисов.

Доступ к каждой системе: MCP-сервер, если подключён (например, `mcp-atlassian` для Jira и
Confluence), иначе REST через `curl` с токеном из переменной окружения (`JIRA_TOKEN`,
`CONFLUENCE_TOKEN`, `BITBUCKET_TOKEN`, …). Нет ни того, ни другого — остановись и попроси доступ.

## Как читать протокол

Это одна связанная цепочка. Порядок шагов обязателен: каждый следующий опирается на результат
предыдущего, и пропуск любого звена уже приводил к ложным выводам.

```
Шаг 0   база знаний: что уже известно (если есть)
Шаг 1   задача: зачем доработка + что делает правка
Шаг 2   документация
Шаг 3   код: 3.0 карта изменений (PR / diff) → 3.1 чтение по ветке задачи
Шаг 3.5 готовность интеграции с партнёром (если есть адаптер / колбэк / мок)
Шаг 4   матрица проверок
Шаг 5   согласование плана              ← без «go» дальше не идти
Шаг 6   предусловия + план отката
Шаг 7   прогон + снятие логов
Шаг 7.5 карточка воспроизведения
Шаг 8   фиксация: 8.1 файл · 8.2 откат · 8.3 комментарий · 8.4 баг
        8.5 тест-кейсы · 8.6 запись в базу знаний
Финал   самопроверка → Definition of Done
```

Если установлены `systematic-debugging`, `verification-before-completion`, `webapp-testing` —
вызывай их по ходу: при расхождении с ожиданием, перед любым «прошло / готово» и для проверок
веб-интерфейса соответственно. Протокол выполняется и без них.

---

## Главные принципы

Полная версия с уроками, рефлексивный протокол и жёсткая самопроверка —
`references/principles-and-lessons.md`. Прочитай её при первом запуске: без уроков правила
выглядят перестраховкой, а с ними понятно, от чего они защищают.

0. **Никаких write-действий во внешние системы без явного запроса.** Комментарии, правки задач и
   страниц, тест-кейсы, PR, merge, push, деплой, сообщения людям — только черновик и вопрос
   «публиковать?». Локальные файлы и личная база знаний — рабочая память, их вести можно.
1. **Факты важнее гипотез.** Утверждение опирается только на код, логи, БД, трейсы, документацию.
2. **Данных не хватает → HYPOTHESIS или BLOCKED.** Не додумывай.
3. **Документация разошлась с кодом → DOC_GAP**, а не автоматический баг.
4. **Негатив доказан только при контрольном позитивном прогоне** на тех же данных.
5. **Перед выводом о баге проверь, не тестовые ли данные и не грязное ли состояние виноваты.**
   SELECT исходного состояния до теста; при сомнении — чистый одиночный прогон.
6. **Перед BUG прочитай требование.** Факт → требование → расхождение → BUG.
7. **Знание из документации записывай сразу при чтении** (если есть база знаний).
8. **План согласуй до тестов.** «Прогони» — не разрешение действовать: сначала матрица, потом
   «go», потом прогон. Данные для тест-кейсов проверь SELECT-ом по стенду.
9. **Откат фикстур обязателен** — эталон до, чистота после, подтверждённая SELECT-ом.
10. **Комментарий разработчика в задаче — приоритетный источник** понимания реализации.
11. **Истина — только код, БД, логи и трейсы.** Чеклист, ТЗ, описание задачи и выводы ИИ — гипотезы.
    Пункт чеклиста противоречит коду → критикуй чеклист.
12. **Не создавай PR, не мержи, не пушь в основную ветку, не деплой без явной команды.**
13. **Сохраняй тестовые данные и способ их составления** — временные файлы сессии исчезнут.
14. **Разбирай каждую ошибку каждого трейса цепочки по тексту лога**: ENV / тестовые данные / логика.
15. **Не утверждай «кода нет» без полной карты изменений** — пустой grep по основной ветке ничего не
    доказывает.
16. **Перед анализом кода сделай `git pull --ff-only`** по ветке задачи — `git fetch` рабочую копию не
    обновляет.
17. **Каждый прогон прозрачен:** запрос целиком, SELECT и результат, traceId с вердиктом по ошибкам,
    ссылка на спеку.
18. **Первый экран сообщения — что сломано, при каком условии, почему важно.** Техдетали ниже.

**Маркировка уверенности обязательна:** `CONFIRMED-live` (воспроизведено + трейс) ·
`CONFIRMED-code` (код / схема) · `вывод` (механизм ясен, в рантайме не пойман) · `contingent`
(зависит от внешнего контракта). Статус и код ответа указывай целиком, особенно когда он **не**
подтверждает вывод.

---

## Алгоритм

### Шаг 0 — База знаний (если есть)

Прочитай обзор архитектуры, поищи по ключу задачи `PROJ-123`, открой заметки затронутых сервисов,
поищи термин задачи на русском и английском. Нашёл — используй как контекст и пропусти дублирующие
запросы, но помечай знание как унаследованное. Подробности и экономия контекста —
`references/knowledge-base.md`.

Заведи рабочий файл сессии `{QA_ROOT}/PROJ-123/RESULT.md` по шаблону `assets/result.md`
(по умолчанию `~/qa/PROJ-123/`).

### Шаг 1 — Прочитать задачу

Через MCP трекера или REST API Jira: description, **все** комментарии,
подзадачи, связанные задачи, ссылки на документацию. Читай дословно, бери первоисточник, не
интерпретируй.

До перехода к шагам 2–3 ответь на два вопроса и запиши ответы в RESULT.md:

> **1. Зачем нужна доработка?** Какую бизнес-проблему решает, что ломается без неё.
>
> **2. Что конкретно делает правка?** Что было до, что стало после.

Почему это важно. Тестировщик, не понимающий бизнес-смысл, проверяет «сделано как написано»
(верификация), а не «решена ли реальная проблема» (валидация). Пример: задача «не перетирать
регистрационный номер партнёра при обновлении карточки». Не зная, что номер нужен для
регуляторной отчётности, не спросишь: «где ещё читается это поле и не сломает ли правка их?»

Критерии приёмки не сформулированы — их можно собрать скиллом `acceptance-criteria`.

### Шаг 2 — Документация

Прочитай все страницы спеки из задачи до конца (MCP или REST API Confluence). Найди
конкретные статусы, поля, очереди, маппинги. Инструкцию читай целиком **перед** действием, а не по
ходу. Новое знание записывай в базу сразу (принцип 7).

### Шаг 3 — Код

Наблюдаешь расхождение с ожиданием — сначала поиск root cause и анализ паттерна, и только потом
чтение кода. Не ищи в коде подтверждение готовой гипотезы.

**3.0 — Полная карта изменений** по протоколу `references/change-map.md`: все PR и ветки во всех
репозиториях (включая общие модели и адаптеры), полный diff ветки против основной, сводная таблица
«репозиторий → PR → методы». Только после неё — любые выводы о коде. До неё статус любого вывода о
реализации — HYPOTHESIS «PR не проверены полностью».

**3.1 — Чтение кода:**

- Читай **по ветке или коммиту задачи, не по основной ветке.** Локальный чекаут — перед любым
  Grep/Read проверь `git branch --show-current` и `git log -1`.
- Читай целиком: контроллеры, сервис, маппер, enum, фича-тоглы, JSON-схемы сообщений.
- Сверь код с документацией → расхождения записывай как DOC_GAP.
- **Убедись контрольным вызовом, что на стенде задеплоена нужная ветка.** Иначе прогон проверяет
  старый код.

### Шаг 3.5 — Готовность интеграции с партнёром

Есть внешний партнёр, адаптер, входящий колбэк или мок — проведи инвентаризацию стенда **до**
матрицы по `references/integration-readiness.md`: продукт в каталоге, версия адаптера на стенде,
реальный партнёр или мок, куда маршрутизируются колбэки, тоглы, существующие сущности, стабы моков,
учётные данные вебхуков, эталон живого пути, процедуры в базе знаний.

Результат — таблица `Компонент | Состояние | Чем проверено`, вывод одной фразой и пронумерованные
пути довести стенд до живого прогона с ценой каждого. Без этого план не согласуется: матрица на
фикстурах при неготовой интеграции проверяет маппинг на твоих данных, а не задачу. Веди
инвентаризацию волнами и после каждой давай человеку одну фразу о том, что уже ясно.

### Шаг 4 — Матрица проверок

Составь матрицу по `references/check-matrix.md`: happy path, negative, edge cases, regression.
Метод — API / SQL / Trace / MQ inject / UI. Каждый негатив — в паре с контрольным позитивом.
Ожидаемый результат — со ссылкой на источник. Данные — реальные id из SELECT по стенду.

### Шаг 5 — Согласовать план

Покажи план по шаблону `assets/plan-for-approval.md`: матрица, предусловия, изменения на стенде с
откатом к каждому, риски, что останется непроверенным. **Дождись явного «go».** До него на стенде
только чтение: SELECT, GET без побочных эффектов, трейсы, конфиги.

### Шаг 6 — Предусловия

Полностью — `references/preconditions-and-test-data.md`. Коротко:

- Данные проверяй чтением до изменений; запись — через `psql` / драйвер (MCP БД часто только читает).
- Рядом с каждым изменением — откат и сохранённый эталон исходного состояния.
- Сообщение в очередь — типы полей строго по JSON-схеме.
- **Тела запросов не выдумывай.** Источники по убыванию достоверности: лог реального вызова в
  трейсе → шаги и вложения тест-кейсов → коллекции запросов (только структура: данные там
  протухают).
- **«Нет данных» — задача, а не итог.** Прежде чем записать проверку в непроверенные, пройди базу
  знаний, тест-кейсы и коллекции; непокрытие фиксируй с предметной причиной.
- **Барьер на штатном пути обходится** (подмена партнёра у записи, вызов серверного обработчика при
  выключенном тогле, вход во флоу с серверной точки). Граница: общие данные — только временно и с
  откатом; нельзя обойти без правки общего — спроси человека.
- Один прогон — свой клиент и чистая сессия браузера.

### Шаг 7 — Прогон

После каждой проверки зафиксируй Evidence: traceId, результат SQL, ответ API целиком.
INCONCLUSIVE пометь и разберись — не считай его PASS. Для каждого негатива выполни контрольный
позитив. Каждую ошибку каждого трейса цепочки классифицируй по тексту лога.

Нет `kubectl`, Kibana или RabbitMQ management — логи и тела запросов часто читаются прямо из
трейсинга. Приёмы (публикация в очередь, Jaeger API, форсирование ветки кода через БД, имена полей
на границе сервисов, camelCase и snake_case, разбор упавшего деплоя) — `references/live-run-techniques.md`.

Увидел похожее на баг — сначала `references/false-bug-checklist.md`.

### Шаг 7.5 — Карточка воспроизведения

После каждого живого действия (сообщение в очередь, вызов с побочным эффектом, фикстура) заполни
карточку `assets/repro-card.md`: исходное состояние, создание данных, действие целиком, проверка
результата, трейс, откат. По ней человек повторит прогон без тебя.

### Шаг 8 — Фиксация результатов

**8.1 Файл.** Обнови `{QA_ROOT}/PROJ-123/RESULT.md`: матрица со статусами, карточки, findings с
типом и уверенностью, тестовые данные, итог самопроверки.

**8.2 Откат фикстур.** Выполни DELETE/UPDATE, проверь чистоту SELECT-ом. Откатывай все поля,
которые трогал сервис, включая служебные и hash-влияющие: неполный откат даёт ложные баги в
следующем прогоне. Удали стабы моков, добавленные в прогоне; верни временно изменённые общие
данные. Откатываются данные — релизы на стенде откатывать не нужно.

**8.3 Комментарий в задачу** — в место, принятое командой для результатов тестирования (обычно
подзадача тестирования, а не родительская задача). Формат — `assets/coverage-comment.md`: требование
→ проверка → полный запрос → результат из БД → кликабельный трейс. Каждый traceId проверь на
существование и соответствие `hasError` перед публикацией. **Публикация — только после явного
«да».** Итог всей сессии (стенд, коммиты, сводная таблица находок) — скилл `test-session-report`.

**8.4 Баг.** Сначала `references/false-bug-checklist.md`, затем оформление по скиллу
`bug-report`; если его нет — по `references/messages-to-people.md`. Первым экраном — что сломано,
при каком условии, как должно быть со ссылкой на источник; причина — только подтверждённая.
Аналитику — без кода и трейсов, разработчику — с точным местом. **Публикация — только после явного
«да».**

**8.5 Тест-кейсы — только по запросу.** Не создавай кейсы, пока человек явно не сказал «да,
создавай». Сначала поищи существующие (по шагам и description, а не только по названию). Шаг =
только действие, ожидаемый результат = только результат, description = одно предложение, один кейс =
одно поведение. Правила — `references/test-cases.md`; работа с Allure TestOps — скилл
`allure-testops-cases`.

**8.6 Запись в базу знаний** (если есть) — по скиллу `obsidian-llm-wiki`. Обязательно: тестовые
данные и способ их составления, реальный код изменения, уроки и ловушки, DOC_GAP, поправки к фактам.
Что именно — `references/knowledge-base.md`.

---

## Самопроверка перед финальным вердиктом

Ни один пункт не отмечается без свежего доказательства, полученного **в этом же сообщении** (SELECT,
трейс, ответ API, diff) — не по памяти о прошлом прогоне и не «должно быть ок». Есть скилл
`verification-before-completion` — пройди его первым. Для каждого утверждения вывода дай три списка:
что выдержало · что поехало (с поправкой) · что осталось непроверенным.

- [ ] Все критерии приёмки задачи покрыты — перечислены явно
- [ ] Каждый PASS подтверждён Evidence
- [ ] Негативные кейсы имеют контрольный прогон
- [ ] Фикстуры откачены, БД чистая (подтверждено SELECT-ом)
- [ ] Findings зафиксированы с типом и рекомендацией
- [ ] Комментарии разработчика в задаче прочитаны
- [ ] Бизнес-смысл доработки понят и записан
- [ ] Каждый BUG подтверждён требованием — иначе статус HYPOTHESIS
- [ ] Полная карта PR собрана — ни одно «метода нет» не сказано без неё
- [ ] Чеклист и ТЗ подвергнуты критике, а не приняты за истину
- [ ] Собственные выводы перепроверены фактами
- [ ] Прочитанная документация записана в базу знаний (если она есть)
- [ ] Тест-кейсы созданы или обновлены по стандарту, если человек об этом просил
- [ ] База знаний обновлена: сервисы, термины, задача, ссылки, уроки (если она есть)

## Definition of Done

Задача готова к продукту, если: все критерии приёмки PASS · нет открытых BUG (допустимы DOC_GAP и
ENV_ISSUE) · тест-кейсы созданы или обновлены, если требовалось · база знаний обновлена, если она
ведётся.

## Типы находок

`BUG` — расхождение с требованием, доказанное фактом и контрольным прогоном · `DOC_GAP` —
документация расходится с кодом · `ENV_ISSUE` — проблема окружения (сервис недоступен, мок не
настроен) · `DEPLOY_MISMATCH` — на стенде не та версия · `TEST_DATA_PROBLEM` — виноваты тестовые
данные. Определения остальных терминов — `references/principles-and-lessons.md`, раздел 5.

## Связанные скиллы

| Скилл | Когда |
|---|---|
| `acceptance-criteria` | собрать критерии приёмки, если их нет в задаче |
| `bamboo-deploy` | выкатить ветки задачи на стенд |
| `wiremock-stubs` | моки внешних партнёров |
| `opensearch-logs` | логи подов, разбор упавшего деплоя |
| `bug-report` | оформление бага |
| `allure-testops-cases` | тест-кейсы в Allure TestOps |
| `test-session-report` | итоговый отчёт по сессии тестирования |
| `obsidian-llm-wiki` | ведение базы знаний |
| `qa-autopilot` | автономный прогон этого протокола агентами |

## Справочники

| Файл | Когда читать |
|---|---|
| `references/project-config.md` | первый запуск: адреса, стенды, репозитории, соглашения |
| `references/principles-and-lessons.md` | первый запуск; перед выводами «баг», «кода нет», «готово» |
| `references/change-map.md` | Шаг 3.0 |
| `references/integration-readiness.md` | Шаг 3.5 |
| `references/check-matrix.md` | Шаги 4–5 |
| `references/preconditions-and-test-data.md` | Шаг 6 |
| `references/live-run-techniques.md` | Шаги 7–7.5 |
| `references/false-bug-checklist.md` | перед любым выводом BUG |
| `references/messages-to-people.md` | Шаги 8.3–8.4, любые сообщения коллегам |
| `references/test-cases.md` | Шаг 8.5 |
| `references/knowledge-base.md` | Шаги 0 и 8.6 |
| `assets/plan-for-approval.md` | Шаг 5 |
| `assets/repro-card.md` | Шаг 7.5 |
| `assets/result.md` | Шаги 0 и 8.1 |
| `assets/coverage-comment.md` | Шаг 8.3 |