测试会话报告

---
name: test-session-report
description: "Итоговый отчёт о сессии тестирования на русском для комментария в Jira или в чат: стенд с коммитами, предусловия, таблица проверок с колонкой «Как проверялось», сводка багов с доказательством фикса, что не проверено, что проверить на проде. Используй всегда, когда просят «оформи итоги тестирования», «отчёт о тестировании», «итог прогона», «что проверили и что нашли», «закончили тестировать». Один баг — это bug-report. English: test summary report, QA sign-off."
license: MIT
compatibility: "Ничего обязательного: скилл формирует текст из материалов сессии. Публикацию в Jira делает пользователь или отдельный инструмент после явного согласия."
metadata:
  author: KonstantinVCH
  version: "1.1.0"
  language: ru
---

# Отчёт о сессии тестирования

Отчёт пишется после прогона и отвечает на четыре вопроса: что настроили, что проверили, что
нашли и починили, что осталось. Его читают аналитик, менеджер и разработчик; через месяц по нему
восстанавливают, почему задачу приняли. Поэтому каждая строка отчёта показывает способ проверки и
доказательство, а не только вывод.

Формат собран по эталонным комментариям реальной команды (сводная таблица багов, настройки
стенда, пошаговый отчёт, компактный отчёт) и доработан там, где эталонам не хватало важного.
Разметка Jira проверена на реальных комментариях.

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

Ссылки на чат команды, шаблоны ссылок на коммиты и трейсы, куда принято писать отчёт (подзадача
тестирования, родительская задача, Confluence), словарь терминов — в
`references/project-config.md`. Заполни один раз.

## Три разных жанра — не путать

| Жанр | Когда пишется | Что внутри |
|---|---|---|
| QA-чеклист | **до** прогона | что собираемся проверить, со ссылками на спеку |
| Баг-репорт (`bug-report`) | по ходу | одна находка: шаги, ОР, ФР, причина, fix |
| **Отчёт о сессии (этот скилл)** | **после** прогона | что настроили, что проверили, что нашли и пофиксили, что осталось |

---

## Структура

Обязательные блоки — 1, 4, 6. Остальные — по ситуации.

```
1. Ссылка на обсуждение в чате           ← всегда, первой строкой
2. Настройки стенда (таблица Что|Коммит) ← если что-то меняли в конфигах
3. Предусловия прогона (список)          ← если они нетривиальные
4. Что проверено (таблица или шаги)      ← всегда
5. Сводная таблица багов/находок         ← если находки были
6. Итог: статус, что не проверено,
   состояние стенда после сессии         ← всегда
```

Эталоны каждого блока — в `references/examples.md`. Форма по умолчанию для прогона проверок без
череды фиксов — компактный отчёт (эталон 4): сразу таблица, без шапки.

---

## Разметка Jira (проверена на реальных комментариях)

```
h1. Заголовок раздела     h3./h4. — подразделы
||Колонка 1||Колонка 2||  ← шапка таблицы
|ячейка|ячейка|           ← строка
*жирный*                  {{моноширинный}}
[текст ссылки|https://…]  ← ссылка
 * пункт списка           ← ПРОБЕЛ в начале строки обязателен
```

**Ловушка моноширинного:** если внутри `{{…}}` есть кавычки-ёлочки, подчёркивания или текст
примыкает к знакам препинания — Jira ломает разметку. Рабочая форма — с пустыми фигурными
скобками: `{{{}ERR_0021 «Переход из статуса NEW запрещён»{}}}`.

**Коммит — всегда ссылкой**, короткий хеш как текст, полный — в URL:
`[bd9645e|{BITBUCKET_URL}/projects/{PROJECT}/repos/order-service/commits/bd9645e94157…]`.

Значки итога в Jira: `(/)` — успешно, `(x)` — ошибка, `(!)` — замечание, `(?)` — не проверено.

---

## Правила

1. **Первой строкой — ссылка на тред обсуждения** в чате команды. По ней восстанавливается
   контекст: кто что говорил, почему приняли решение. Без неё отчёт висит в вакууме. Ссылки нет —
   оставь плейсхолдер `<ссылка на тред>` и скажи об этом пользователю.

2. **«Фактический результат» пишется ДО фикса и с числами.** Не «не работало», а «0 доставок за
   всю жизнь очереди (`publish_in=2/out=0`)», «19 сообщений потеряно», «заказ навсегда оставался
   `NEW`». Цифра показывает масштаб и доказывает, что смотрели, а не гадали.

3. **После фикса — доказательство, что починилось.** В той же ячейке: «После фикса живьём:
   `NOT_SAVED → REJECTED_TECHNICAL_ERROR`, трейс `7e329a08…`». Баг без подтверждения фикса — это не
   «пофикшено», а «обещано».

4. **Каждый шаг проверки — с трейсом.** Формат: короткое действие → результат → ссылка на трейс
   с `?uiFind=<spanId>` на нужный спан, а не на трейс целиком.

5. **Настройки стенда — с коммитами и объяснением, почему без этого не работало.** Не просто
   «поправили порт», а «сервису был прописан мок соседнего адаптера, исправлено на свой — до этого
   путь резерва не работал никогда».

6. **Предусловия — то, без чего прогон не воспроизвести:** флаги, товары и партнёры, требования
   к статусу пользователя, обязательные поля. Формулируй как ограничение с последствием:
   «пользователь должен быть `VERIFIED` — под `UNVERIFIED` заказ встаёт на „Ожидает подтверждения
   личности“ и на склад не уходит».

7. **«Не проверено» — обязательно, в одном из двух видов.** Целая область не покрыта (нет стабов,
   партнёр метод не реализовал, нет данных) → отдельным блоком в итоге. Конкретная находка не
   доведена → статусом `Не проверено: <чем заблокировано>` в таблице. Отчёт без этого читается как
   «проверено всё».

8. **Состояние стенда после сессии — обязательно**, если что-то осталось: моки и стабы,
   несмерженные ветки конфигов, тестовые данные, режимы деплоя. Иначе следующий тестировщик ловит
   чужие хвосты и не понимает, откуда они.

9. **Скоуп находок.** Находка вне задачи помечается прямо в таблице, иначе она блокирует
   приёмку. Как определять скоуп (менялся ли код в PR, специфично ли для флоу, требовала ли
   постановка) — правило 11 скилла `bug-report`.

10. **Отчёт — туда, где команда его ищет.** Если в проекте есть подзадача тестирования — в неё, а
    не в родительскую задачу (в родительскую — короткая сводка со ссылкой). Принятое место —
    в `project-config.md`.

11. **Пиши простыми словами.** Отчёт читают аналитик и менеджер, а не только разработчик. Имена
    классов, полей, очередей и статусов оставляй как есть — это факты. Описание вокруг них должно
    читаться без словаря:

    | Не писать | Писать |
    |---|---|
    | изменение аддитивное | новая ветка добавлена рядом со старой, старую не трогали |
    | это ENV | это проблема стенда, а не задачи |
    | DOC_GAP | документация расходится с кодом |
    | фикстуры не создавались | тестовых данных вручную не подкладывал |
    | значение эхо-переносится | значение копируется из исходного запроса как есть |
    | инжект в очередь | отправка сообщения в очередь вручную |
    | нарастающий backoff | пауза между попытками растёт |
    | SNAPSHOT-зависимость | нерелизная версия библиотеки |
    | вне скоупа | вне задачи |

    Проверка: дай прочитать человеку, который не сидел в этой сессии. Споткнулся о слово — слово
    заменить.

12. **Не выноси в отчёт служебную очевидность.** Строка отчёта — проверка задачи, а не отчёт о
    собственной подготовке. «На стенде ветка, а не master», «сервис отвечает 200», «БД доступна»,
    «деплой прошёл» — не проверки: без них прогона просто не было бы.

    Признак служебной строки: её результат заранее известен, иначе прогон бы не состоялся.

    | Не строка отчёта | Куда девать |
    |---|---|
    | на стенде задеплоена ветка задачи | «Настройки стенда», строка с коммитом |
    | сервис поднялся, `/health` = 200 | никуда, это условие прогона |
    | подключение к БД стенда работает | никуда |
    | тестовые данные подготовлены | предусловия, если они нетривиальны |

    Исключение одно: подтверждение версии идёт отдельной проверкой, если сам факт был под
    вопросом — например, деплой прошёл с master вместо ветки, и это выяснилось по ходу. Тогда это
    уже находка.

13. **В таблице проверок — столбец «Как проверялось».** Без него «PASS» приходится принимать на
    веру, а повторить проверку нельзя. Коротко и по делу: `POST /reports/generate?reportDate=2026-04-21
    после подмены delivery_type у строки 282`, `SQL выборки прогнан в двух редакциях на одних данных`,
    `сверка db.statement из трейса с эталоном ветки, sha256`.

    Минимальная форма таблицы:
    ```
    ||Что проверялось||Как проверялось||Итог||Результат + доказательство||
    ```

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

    | Итог | Когда |
    |---|---|
    | ✅ Успешно | поведение соответствует ожидаемому |
    | ❌ Ошибка | поведение расходится с ожидаемым, есть дефект |
    | ⚠️ Замечание | работает, но с оговоркой: пробел в покрытии, поведение вне задачи |
    | ⏳ Не проверено | не дошли, причина — в той же ячейке |

    Типичная ошибка: в «Результате» «создана строка 372, трейс …» без признака. Успех очевиден
    автору, но не читателю: тот не знает, строка должна была создаться или наоборот.

    «Результат» — дословные значения и ссылка на трейс либо строка БД. «Как» — воспроизводимое
    действие **в одну-две человеческие фразы, без погружения в механику**. Если способ
    нестандартный (запрос прогнан в двух вариантах, значение сравнивалось посимвольно, текст
    запроса взят из чужого планового вызова) — скажи прямо, иначе решат, что проверка была живой,
    хотя она была расчётной.

    Ни «что», ни «как» не пишутся внутренним жаргоном. Формулировку, которую нельзя произнести
    вслух коллеге, — переписать:

    | Нельзя | Как сказать |
    |---|---|
    | литералы маппера совпадают с фильтром | система записывает тот же тип доставки, который потом ищет при проверке на повтор |
    | дифференциал двух редакций SQL | прогнал запрос в старом и новом варианте на одних данных |
    | сверка по кодовым точкам / побайтная сверка | сравнил значения посимвольно |
    | атрибуция строки по окну вызова | убедился, что запись создал именно мой вызов, а не фоновая задача |
    | негатив с контрольным позитивом | проверил, что без мешающей записи отчёт формируется, а с ней — нет |
    | предикат отсечения не сработал | заказ не попал в выборку из-за статуса |

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

14. **Ошибка в отчёте не бывает голой.** «Ошибка 500, сервис падает» — недописанная строка:
    читатель не знает, авария это или проверка негативного сценария, и что теперь делать. Любая
    ошибка описывается четырьмя элементами, все обязательны:

    1. **точный код и текст** — `HTTP 500, SHOP.ERR.9999`, а не «упало»;
    2. **ссылка на трейс, где этот код получен** — иначе слово против слова;
    3. **ожидаемо или нет** — «так и должно быть по спеке, проверяли негативный сценарий» либо
       «ожидался успех, это дефект»;
    4. **что с этим делать** — заведён баг и его номер, вопрос аналитику, принято как есть,
       поведение вне задачи.

    Без пункта 3 отчёт пугает напрасно: половина ошибок в прогоне — намеренные. Без пункта 4
    находка повисает: прочитали, испугались, никто не взял.

    ```
    ❌ HTTP 500 SHOP.ERR.9999 при формировании отчёта по заказу без типа доставки.
    Трейс: <ссылка>. Ожидался отказ с понятной ошибкой, получено падение сервиса.
    Поведение существует и до этой задачи, её правки кода не касались — заведена отдельная
    задача, приёмку PROJ-123 не блокирует.
    ```

15. **Никакой внутренней кухни процесса.** Отчёт читают аналитик, менеджер и бизнес — им нужны
    факты о продукте, а не рассказ о том, как устроена работа QA. Из отчёта вычищаются: агенты и
    субагенты, «карточки», волны и фазы прогона, названия внутренних скиллов и файлов, счётчики
    раундов ревью, «перепроверяет второй агент», «оркестратор», номера TC-N как единственный
    идентификатор проверки. Для читателя это шум, который вдобавок подрывает доверие к результату.

    Причина в «не проверено» тоже формулируется предметно:

    | Не писать | Писать |
    |---|---|
    | ревью доказательств не запускалось | проверка ещё идёт / результат будет дополнен |
    | карточка TC-14 не готова | оплата частями живьём не проверена: заказ без подтверждения |
    | волна 6 в работе | подарочные карты и четыре смежных метода — в работе |
    | второй агент перепроверяет | — (не упоминать вовсе) |
    | плановый BLOCKED по TC-11 | постаматы и самовывоз: заказов на стенде нет, 0 из 46 |

    Проверка: в тексте не осталось ни одного слова, которое имеет смысл только внутри вашего
    рабочего процесса.

16. **Сначала определи, финальный ли это отчёт — от этого зависит состав.** Финальный — если
    живых проверок по задаче больше не планируется: план закрыт или остаток объяснён, тестовые
    данные откачены, стенд возвращён в исходное состояние, задача уходит на приёмку и выкатку.
    Промежуточный — если работа продолжается: обычная форма плюс строка, что проверка ещё идёт.

    **Финальный обязан содержать блок «Что проверить на проде».** Всё доказанное доказано на
    стенде, а у прода другие объёмы, история и состав данных. Без этого блока после выкатки никто
    не знает, на что смотреть, и первым сигналом проблемы становится жалоба бизнеса.

    Что в блоке, все пункты обязательны:
    * **готовые запросы, а не описания** — `select …` целиком, копируется и выполняется как есть;
    * **разделение по времени: до выкатки и после** — до показывает исходное состояние данных и
      объём риска, после доказывает, что новая логика работает;
    * **у каждого запроса — ожидаемый результат и что означает отклонение** («ожидаемо пусто»,
      «строка здесь означает, что заказ отчитался дважды»);
    * **главная проверка названа отдельно** — единственный запрос, который ловит поломку сути
      задачи; обычно инвариант: дублей нет, пустых значений нет, суммы сходятся;
    * **оговорки, где запрос может соврать** — пересекающиеся идентификаторы, join не по тому
      ключу, значение вычисляется асинхронно и в момент проверки ещё пустое.

    Ссылки на прод-логи и трейсы — **только проверенные**: открыл, получил ответ, увидел данные.
    Не проверил — пиши прямо: «ссылку не даю, адрес отвечает 404». Нерабочая ссылка в финальном
    отчёте хуже её отсутствия: по ней не пойдут, а проверку посчитают закрытой.

    Разница с «не проверено»: туда идёт то, что не смогли, а надо было; в «что проверить на проде» —
    то, что принципиально проверяется только на боевых данных. Скелет блока — в
    `references/examples.md`.

17. **Никаких голых номеров багов — ни в отчёте, ни в сводке.** «Исправлено: BUG-1, BUG-2,
    BUG-4» читателю ничего не говорит: это внутренняя нумерация сессии, в трекере её нет. Каждый
    исправленный и каждый оставшийся пункт — три части, все обязательны:

    1. **что было сломано — человеческими словами, как кейс**: «order-service не стартовал — в
       конфиге не было адреса catalog-service», а не «BUG-1»;
    2. **чем подтверждено, что починилось** — трейс или результат живой проверки;
    3. **ссылка на коммит фикса** — `[короткий хеш|полный URL]`, для нескольких репозиториев — через `+`.

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

    ```
    Плохо:  Исправлено: BUG-1, BUG-2, BUG-4, BUG-7, BUG-5 (часть 1).
    Хорошо: Исправлено:
     * order-service не стартовал без адреса catalog-service в конфиге — [0838aec|…]
     * партнёр получал одно изменение 2–3 раза — теперь одно, [трейс|…] — [a68e6a3|…] + [9a7ee4f|…]
    ```

    *(Реальный случай: сводка ушла со строкой «Исправлено: BUG-1, BUG-2, BUG-4, BUG-7». Ответ
    читателя: только конкретика — какой кейс исправлен, со ссылкой на коммит, иначе непонятно.)*

18. **Ссылка на трейс — только по traceId, и его длину проверь.** В OpenTelemetry и современных
    клиентах Jaeger traceId — 32 шестнадцатеричных символа, spanId — 16. Шестнадцать символов в
    заметках чаще всего означают спан: ссылка `{JAEGER_URL}/trace/<spanId>` откроет «trace not
    found», и доказательство в отчёте окажется битым.

    - 32 символа — ставь ссылку как есть.
    - 16 символов — открой ссылку до отправки. Трейс не нашёлся — это спан: найди traceId по
      сервису и времени или спроси автора заметок. Нашёлся — в проекте 64-битные traceId старого
      клиента Jaeger, ссылка рабочая.
    - Проверить не получилось — пиши «трейс: `<id>` (не проверен, возможно spanId)», без ссылки.

    *(Случай из прогона скилла на тестовом запросе: в заметках было «traceId b7ad6b7169203331», и
    отчёт сделал из него ссылку `/trace/b7ad6b7169203331` без проверки. Это 16 символов — по всей
    видимости, ID спана.)*

---

## Если фиксов не было

Сессия часто заканчивается находками без фиксов. Тогда вместо «Сводной таблицы пофикшенных
багов»:

```
h1. Находки за сессию PROJ-123
||№||Заголовок||Фактический результат||Статус||
|*1*|<что>|<дословные значения + трейс>|Ждёт фикса (сообщено разработчику)|
|*2*|<что>|<…>|Вне задачи — поведение платформы, вопрос аналитику|
|*3*|<что>|—|Не проверено: <чем заблокировано>|
```

Столбец «Коммит фикса» заменяется на «Статус». Словарь статусов — брать из него, не изобретать:

| Статус | Когда |
|---|---|
| `Пофикшено` + ссылка на коммит | фикс есть и подтверждён живьём |
| `Ждёт фикса (сообщено разработчику)` | дефект в скоупе, репорт передан, фикса пока нет |
| `Ждёт решения аналитика` | несогласованный контракт: спека требует того, чего система не умеет |
| `Вне задачи — <чем обосновано>` | поведение было до задачи, её правки его не касались (правило 9) |
| `Не дефект — <обоснование>` | ожидание оказалось неверным, код уже соответствует требованию; пункт снять |
| `Не проверено: <чем заблокировано>` | не дошли: нет стабов, партнёр не реализовал метод, нет данных |

Два статуса обязательны к использованию, даже если хочется промолчать: **«Ждёт фикса»** — иначе
находка теряется между сессиями и всплывает на проде как новая; **«Не проверено»** — иначе отчёт
читается как исчерпывающий. Пустой столбец не оставлять, «—» вместо статуса не писать.

---

## Внутренний критик (обязательный отдельный проход)

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

Полный список паттернов, запрещённые обороты, процедуру и то, чего критик НЕ трогает (числа,
тексты ошибок, имена полей, фактические отрицания), — в `references/neuro-critic.md`. Прочитай
его перед первым отчётом в сессии.

---

## Два адресата — две разметки

Один и тот же отчёт живёт в двух местах, и разметка у них разная:

- **комментарий в задаче Jira** — разметка Jira: `||…||`, `{{моно}}`, коммиты ссылками;
- **сообщение в чат команды** (Slack, Mattermost, Telegram) — Markdown. Таблицы Jira, `{{моно}}` и
  `[текст|url]` там не рендерятся и читаются как мусор. Ссылки — короткие гиперссылки, хеш
  коммита семью символами.

Фактура одна, меняется разметка и длина: в чат идёт сводка со ссылкой на полный отчёт.

## Порядок блоков

Сводка первой: что тестировали, на каком стенде, итог одной фразой. Дальше — «Что проверяли»,
«Конфигурация стенда», «Что не проверено». Если прогон задевал внешние контуры (партнёры,
почтовые и SMS-шлюзы), добавь блок «Куда данные уходили, а куда нет» с прямым перечислением
адресов.

Читатель должен понять итог из первых трёх строк, не разворачивая таблицы.

---

## Чеклист перед выдачей

- [ ] Первой строкой — ссылка на тред обсуждения
- [ ] Настройки стенда с коммитами и объяснением «почему без этого не работало»
- [ ] Предусловия сформулированы как ограничение с последствием
- [ ] Каждый шаг проверки — с трейсом на конкретный спан
- [ ] «Фактический результат» — с числами и до фикса
- [ ] У каждого фикса — доказательство, что починилось (трейс/данные после)
- [ ] В таблице проверок есть столбцы «Как проверялось» и «Итог» с явным признаком (✅ / ❌ / ⚠️ / ⏳)
- [ ] В отчёте нет служебной очевидности (задеплоена ветка, сервис отвечает, БД доступна)
- [ ] В тексте нет внутренней кухни: агентов, волн, карточек, фаз, номеров TC как единственного имени проверки
- [ ] У каждой ошибки: точный код, ссылка на трейс, ожидаемость и что делать
- [ ] Скоуп находок помечен
- [ ] Определено, финальный отчёт или промежуточный
- [ ] Для финального: блок «Что проверить на проде» — готовые запросы, до/после выкатки, ожидаемый результат у каждого, названа главная проверка
- [ ] Ссылки на прод-логи проверены открытием; непроверенные не вставлены
- [ ] Есть блок «не проверено», и в нём нет «нет данных на стенде» без разбора: сначала база знаний команды → тест-кейсы в системе тест-менеджмента → коллекции запросов (Bruno/Postman) — как создать нужные данные
- [ ] Есть состояние стенда после сессии (моки, ветки, данные, режимы)
- [ ] Разметка Jira: таблицы `||…||`, моно с `{{{}…{}}}` где нужно, коммиты ссылками
- [ ] **Нет голых номеров багов** (правило 17), в том числе в короткой сводке для родительской задачи
- [ ] Ссылки на трейсы построены по traceId из 32 символов; 16-символьные ID проверены открытием (правило 18)
- [ ] Отчёт адресован туда, где команда его ищет (правило 10)
- [ ] **Пройден внутренний критик** — отдельным проходом, после написания текста
- [ ] Каждая находка из таблицы уже оформлена баг-репортом (`bug-report`) или будет отдельно

---

## Чего нет в типичных эталонах, но должно быть

Эталоны команд сильны в фактуре, но три вещи в них обычно отсутствуют — выше они обязательны:

1. **«Не проверено».** Без него отчёт читается как исчерпывающий, и дырка в покрытии всплывает
   уже на проде.
2. **Состояние стенда после сессии.** Эталоны описывают, что *настроили перед* прогоном, но не
   что *осталось после*. Реальный случай: остались стабы на общем WireMock, адаптер в режиме мока
   без стабов на половину путей, входящий роутинг партнёра на неслитой ветке и три записи
   каталога в БД — всё это ломает соседям сценарии, и никто об этом не знает.
3. **Скоуп находок.** Без пометки платформенное поведение попадает в приёмку задачи и блокирует её.

Чего добавлять НЕ надо, хотя рука тянется: пересказ чеклиста, длинные куски кода, полные тела
запросов. Для этого есть баг-репорт и коллекция запросов — в отчёте о сессии они превращаются в
шум.

---

## Границы скилла

Скилл описывает **только формат текста**. Готовый отчёт выдаётся в чат — пользователь сам решает,
куда его девать. Ничего не публиковать, комментарии не создавать и не редактировать без явной
просьбы.

Связанные скиллы: `bug-report` (одна находка), `qa-task-testing` (полный QA-протокол задачи),
`acceptance-criteria` (критерии приёмки — по ним удобно строить таблицу «Что проверялось»).

## Справка

- `references/examples.md` — эталоны блоков отчёта и скелет «Что проверить на проде»
- `references/neuro-critic.md` — внутренний критик: нейропаттерны
- `references/project-config.md` — настройки проекта