Test Cases

---
name: test-cases
description: Составление тест-кейсов по best practice QA с экспортом в CSV для импорта в Zephyr Scale (Option 1) или созданием напрямую через MCP вашей TMS. Используй, когда пользователь просит сгенерировать, составить или подготовить тест-кейсы, чек-листы или CSV для импорта в TMS.
allowed-tools:
  - Read
  - Write
  - AskUserQuestion
---

Составь тест-кейсы по правилам ниже. Сначала готовь их в md-файле для валидации, затем — CSV для импорта (или прямое создание через MCP, раздел 13).

Учитывай логику требований и существующие макеты. При расхождении между макетом и реализацией — фиксируй вопросом аналитику.

0. Полнота источников и честность ограничений:
   - Перед генерацией собери ВСЕ источники и держи их статус явно. В итоговом отчёте
     приведи таблицу источников: тикет / вложения тикета / связанные задачи / вики
     (Confluence) / выгрузка Figma / визуальный просмотр ВСЕХ фреймов / комментарии
     Figma / реализация (если есть) — по каждому: изучен | не изучен | чем заблокирован.
     «Не изучен» без причины и плана обхода — недопустимое состояние отчёта.
   - Упёрся в ограничение инструмента (обрезанный ответ MCP, недоступный файл, упавший
     субагент) — НЕ деградируй молча: сразу сообщи пользователю и предложи обход.
     Типовой пример: вложения тикета через MCP трекера обрезаются по размеру ответа —
     те же файлы часто лежат на связанных страницах вики, откуда их можно скачать
     инструментом, сохраняющим файл на диск целиком (для Confluence —
     `confluence_download_attachment`).
   - Самоотчёт субагента («прочитал всё, пропусков нет») — не доказательство: факты,
     на которых строятся ОР (тексты, состав полей, лейблы, ЧИСЛА — размеры, отступы,
     gap), перепроверяй точечно
     по первоисточнику (визуал фрейма, файл, живая система).
   - Комментарии Figma через MCP недоступны (`get_figma_data` их не отдаёт): ДО генерации
     ТК явно запроси у пользователя комментарии из макета (текстом или скриншотами) —
     в них часто живут правки поверх макета (тексты ошибок, убранные поля, финальные
     формулировки). Пока комментариев нет — источник числится незакрытым, об этом
     сказано в отчёте.

1. Формат тест-кейсов:
   - Наименование — короткое и понятное (объект: суть проверки, как «Открытие
     календаря», «Пагинация списка»). Без URL, селекторов и технических деталей
     в названии (им место в шагах/objective). Не пиши в названии TC-(номер ТК).
   - Предусловия выполнения тест-кейса (если применимо)
   - Шаги (максимально подробные, атомарные)
   - Ожидаемый результат (указывай только после логически значимых шагов)
   - Приоритет (High / Normal / Low)
   - Тип (UI / Functionality / Integration — или значения, принятые в вашем проекте)
   - Reference (ссылка или название макета из Figma/PDF, конкретный элемент) - если применимо
   - Использовать ТОЧНЫЕ названия полей, кнопок, заголовков,
     плейсхолдеров как в реализации/макетах/ТЗ
   - Если в макете поле называется «Кем выдан?» — писать «Кем выдан?»,
     не «Кем выдан ДУЛ»
   - Проверять: двоеточия, вопросительные знаки, регистр,
     пробелы в лейблах
   - Если названия в требованиях и макетах расходятся —
     фиксировать как вопрос для аналитика

2. Шаги:
   - Каждый шаг — одно действие
   - Обязательно указывать:
     • "Кликнуть по кнопке «Название кнопки»"
     • "Ввести значение «…» в поле «Название поля»"
     • "Выбрать значение «…» из выпадающего списка «Название»"
     • "Навести курсор на элемент «…»"
     • "Открыть страницу по URL …"
   - Избегай ссылок-сокращений:
     ❌ «аналогично», «повторить шаги», «как в предыдущем тест-кейсе»,
     ❌ «выбрать значения согласно названию ТК»
     Каждый шаг должен читаться независимо от других ТК.

3. Ожидаемый результат:
   - По умолчанию — отдельный Expected Result после значимых шагов, а не один общий в конце
   - Указывай результат после шагов, где:
     • происходит валидация
     • меняется состояние UI
     • отправляются данные
     • отображается ошибка/сообщение и тд
   - Формулировка:
     • "Система отображает…"
     • "Поле подсвечивается ошибкой…"
     • "Кнопка становится активной/неактивной…" и тд
   - Источник ОР — требования/ТЗ, затем макеты. Реализация/стенд — НЕ источник ОР:
     из реализации берутся только точные названия элементов, а ожидаемое
     ПОВЕДЕНИЕ — из требований и макетов. Если реализация расходится
     с требованиями — это баг или вопрос аналитику, а не основа для ОР.
   - ЗАПРЕЩЕНЫ в ТК формулировки «зафиксировать на прогоне», «уточнить по факту
     реализации», «сверить с реализацией»: они превращают тестирование в
     документирование того, что сделали. Неизвестный текст/поведение — это
     вопрос аналитику ДО прогона (раздел 11); в ОР — наблюдаемый ожидаемый
     смысл. Единственное исключение — снятие эталона с работающей PROD-реализации
     того же требования (например, текст той же валидации на действующей форме),
     когда аналитик явно подтвердил «требование то же».

4. Покрытие:
   **Негатив — обязательный артефакт, не опция.** Выдели отдельную группу «Негатив/Границы»; в оценке покрытия (раздел 12) перечисли, какие негатив-классы закрыты и какие осознанно пропущены (с причиной). Позитив-only набор неполон, даже если объект кажется простым/навигационным.
   **Оверлеи/модалки/панели (пример пака под тип объекта):** блокировка прокрутки (позиция сохраняется, фон не скроллится, компенсация ширины скроллбара без «прыжка»), закрытие ×/Esc/клик по фону/Back, deep-link и перезагрузка (состояние в URL), даблклик/спам, ресайз при открытом, стекинг оверлеев, **навигация при открытом оверлее** (смена вкладки/таба, переход по внутренней ссылке, Back/Forward: оверлей закрывается или остаётся управляемым, не зависает поверх нового экрана, не перехватывает клики, и его есть чем закрыть - триггер не пропал вместе со сменой контекста), **вмещаемость во вьюпорт на КАЖДОМ брейкпоинте (вкл. планшет и короткий/ландшафтный экран): контент не обрезается по вертикали И по горизонтали (не уезжает за края), при контенте выше вьюпорта — внутренний скролл, все элементы и кнопки (submit/футер/закрытие) доступны, безопасные отступы от краёв**. У других типов объектов — свой негатив-пак (формы, списки, навигация, API; см. references).
   **Повторяющиеся блоки и динамические коллекции (добавить/удалить N участников, товаров, адресов, файлов) — отдельные ТК, а не строчка внутри ТК на отправку.** Типичная дыра проектирования: пишут «Добавление элемента», «Удаление элемента», «Лимит» и «Отправка с добавленными» — покрытие выглядит полным, хотя главное не проверяется: ЧТО РЕАЛЬНО УХОДИТ В ЗАПРОСЕ при каждом количестве. Закладывать минимум три ТК:
   • **Состав запроса при каждом количестве** — 0, 1, 2, … максимум; в ОР указывать число элементов массива И полный состав, а не «заявка отправлена». Промежуточные количества обязательны: ошибка сборки массива проявляется на 2-3 элементах, а не на границах.
   • **Состав запроса после удаления перед отправкой** — удаление из начала, из середины и с конца; середина критична (при `key` по индексу данные блоков разъезжаются). ОР: ушёл именно оставшийся состав, без сдвига.
   • **Валидация внутри блока** — обязательность, допустимые символы, форматы, границы проверяются на добавленном блоке, а не только на первичных полях формы; отдельно фиксировать, чем правила блока ОТЛИЧАЮТСЯ от основной формы (например, к участнику не применяется ограничение по возрасту).
   В тестовых данных таких ТК — **уникальные значения в каждом блоке** (Alpha/Beta/Gamma, разные даты с различимыми днём и месяцем: 11.01, 22.02). Одинаковые данные скрывают перепутывание и сдвиг, а 01.01 маскирует перестановку дня и месяца при конвертации в ISO.
   Включай в покрытие:
   - Позитивные сценарии
   - Негативные сценарии
   - Граничные значения
   Не дублируй одинаковые проверки без причины.
   - UI-состояния:
     • default
     • hover
     • focus
     • disabled
     • error
     • loading (если применимо) и тд
   - Поведение при:
     • перезагрузке страницы
     • навигации
     • потере сети (если есть интеграции) и тд
   - Должна быть качественная оптимизация, но не терять качество и покрытие
   - Проверки производятся на разрешениях (если задача связана с UI/адаптивом):
     Desktop: 1920x1080, 1536x864, 2560x1440
     Mobile: 414x896, 360x800, 393x873, 430x926
     Tablet: 768x1024, 1024x768
   - **Целостность вёрстки на КАЖДОМ брейкпоинте — для ЛЮБОГО объекта, не только модалок:** ничего не обрезается по вертикали и по горизонтали и не уезжает за края; все элементы, тексты, иконки и кнопки видимы и доступны; при контенте выше вьюпорта — скролл (для оверлеев внутренний); состав и расположение сверяются с макетом ИМЕННО для этого брейкпоинта (пункт не должен пропасть, переехать или сменить сторону иконки). Модалки/оверлеи — лишь частный случай.
   - **Выравнивание проверять геометрически, а не «на глаз»:** для «по центру» — центр элемента совпадает с центром контейнера/вьюпорта (допуск ~1-2px); для лево/право — отступы от края; для симметрии — равенство парных отступов. Наличие элемента ≠ правильная позиция. Крайние ширины (2560+ и минимальная поддерживаемая проектом mobile-ширина, обычно 360) проверять И на overflow, И на центрирование/выравнивание — там чаще всего ломается layout-математика (fixed left, max-width контейнер, grid, absolute).
   - Повторное использование формы:
     • работоспособность после успешной отправки и возврата
       (кнопка «Отправить ещё» и т.п.)
     • корректность всех полей и списков при повторном заполнении
   - Последовательная валидация:
     • смена типа ошибки при изменении ввода
       (например: ввод латиницы → стирание → ошибка должна
       смениться с «Только кириллица» на «Обязательное поле»)
     • независимость ошибок между полями
       (ошибка в поле А не влияет на текст ошибки в поле Б)
   - Точные тексты ошибок:
     • указывать ожидаемый текст ошибки в Expected Result,
       а не абстрактное «отображается ошибка»
       Если текст ошибки неизвестен - указывать ожидаемый смысл
   - Если поле имеет дополнительные UI-элементы
     (кнопка «Нет отчества», тогл, иконка очистки) -
     проверять их наличие/отсутствие и поведение отдельно

5. Сверка с реализацией и макетами:
   - При наличии макетов/скриншотов — сверять тест-кейсы с ними
   - Figma — ОБЯЗАТЕЛЬНО смотреть макет ГЛАЗАМИ, а не только его структуру:
     выгрузка дерева (`get_figma_data`) даёт сетку и layout текстом, но часть контента
     скрыта в шаблонах компонентов (`template=…`) и в выгрузку не попадает; различия
     между брейкпоинтами (desktop/mobile) в дереве не видны. Дополнительно скачивать
     отрисованные фреймы и просматривать ВСЕ фреймы объекта — каждый экран/состояние,
     desktop И mobile (`download_figma_images`). Выборка «ключевых» фреймов запрещена:
     расхождения живут именно в непросмотренных (заполненные состояния, мобильные
     варианты, модалки). Только визуал даёт точные подписи кнопок/карточек, полный
     состав групп и ловит расхождения между брейкпоинтами; выравнивание/ширины кнопок
     из текстовой выгрузки не выводить — только по картинке. ЧИСЛОВЫЕ РАЗМЕРЫ (высоты
     блоков, отступы, gap) из выгрузки не выводить вовсе: внутри фрейма-обёртки лежит
     растр со СВОИМИ `dimensions` — часто шире и выше контейнера, `absolute`, со
     смещением, обрезается контейнером; это размер КАРТИНКИ, а не блока. У контейнеров
     с `sizing: hug` фактической высоты в выгрузке нет совсем. Размер проверять по
     экспорту PNG и арифметикой: высота карточки = картинка + gap + строки подписи;
     ширина ленты = сумма карточек + gap×(n−1) — так же проверяется и сам gap.
     Просмотренные фреймы
     фиксируй в таблице источников (раздел 0); демо-данные макета, противоречащие его
     же валидации (кириллица в поле «латиницей»), — в вопросы аналитику
   - **При ПРОГОНЕ ТК по реализации действует то же правило, что и для макета: смотреть
     ГЛАЗАМИ.** DOM, `innerText`, снапшот доступности и computed-стили дают структуру,
     тексты и поведение, но слепы к оформлению - так пропускается не тот вариант
     компонента (серая кнопка вместо белой с обводкой), сбитые отступы, шрифты,
     радиусы, подменённые иллюстрации. По каждому проверяемому состоянию снимать
     скриншот реализации и открывать его рядом с фреймом макета; отдельно прогонять
     hover/focus/active - их в DOM нет вообще. Не сохранился скриншот - блокер шага,
     а не повод продолжать. Результат «проверено» без единого просмотренного
     скриншота реализации недопустим
   - **Числа из спецификации разработчика привязывать к брейкпоинту.** Токены отступов
     часто различаются между desktop и mobile при одинаковой структуре: прежде чем
     впечатать число в ОР, уточнить, для какой раскладки оно названо, и сверить
     с макетом ИМЕННО этого брейкпоинта. Одно число, растиражированное на все ТК, —
     готовый ложный Fail.
   - По умолчанию ОР пишутся 1в1 с макетом (точные заголовки, тексты, полный состав
     списков/групп, названия, иконки) — дефолт максимальной точности. Послабление по
     контенту — ТОЛЬКО когда пользователь явно просит не привязываться к контенту
     (напр. наполнение тестового стенда отличается от макета): тогда проверять наличие
     блока и ключевые названия/заголовки/иконки, не впечатывая жёсткий полный перечень.
     Структуру, заголовки и ключевые названия сверять точно всегда
   - Расхождения фиксировать как баги или вопросы
   - Если поле по требованиям «необязательное»,
     но в реализации требует ввода — это баг

6. Интеграции:
   Если есть API / внешние сервисы:
   - Проверять:
     • корректную отправку параметров
     • обработку ошибок 4xx / 5xx
     • отсутствие падений UI и тд
   - Указывать это в шагах и Expected Result

7. Структура:
   - Порядок ТК: сначала High, затем Normal, затем Low
   - Внутри каждой группы сначала позитивные сценарии, затем негативные
   - Группируй логически (Отображение / Валидация / Навигация / Негатив)
   - Разделяй Desktop и Mobile, если есть адаптив
   - Целевые браузеры — по требованиям проекта; типовой минимум:
     Chrome (Desktop + Android), Safari (iOS)
   - Для Mobile-only ТК добавляй префикс `[Mobile]` в название

8. Стиль:
   - Деловой, QA-стиль
   - Без воды
   - Четко, однозначно, воспроизводимо

9. Результат:
   - Тест-кейсы должны быть готовы к импорту в TMS (CSV)
   - Если подключён MCP вашей TMS (например, Zephyr Scale MCP с инструментом
     create_test_case) — после валидации md-файла предложи пользователю создать
     ТК напрямую вместо ручного импорта CSV; CSV остаётся как fallback
   - Без сокращений и неоднозначных формулировок
   - Имя файлов: `{TASK_KEY}_test_cases.md` и `{TASK_KEY}_test_cases.csv`
     (например: `PROJ-1234_test_cases.md`). Сохранять в текущую рабочую директорию.

10. Экспорт для Zephyr Scale
- Генерировать CSV в формате "Option 1" (Steps):
  Колонки строго: Name, Status, Step, Expected Result, Preconditions, Priority, Type
- Правило строк:
  1 строка CSV = 1 шаг
  Для первого шага тест-кейса заполнять Name и Status
  Для последующих шагов этого же тест-кейса оставлять Name и Status пустыми
- Expected Result заполнять для каждого шага (в той же строке)
- Кодировка: UTF-8
- Разделитель: запятая (,)
- Все поля экранировать кавычками (") при необходимости (запятые/переносы/кавычки)
- Не использовать переменные/плейсхолдеры вида {…} в CSV (писать текстом)

11. Анализ требований и уточнения

Различай два типа вопросов по неоднозначностям:

**Критичные для генерации** — без ответа невозможно корректно составить ТК (противоречие в макете и описании, неясный happy path, неизвестное поведение валидации, отсутствует ключевой сценарий):
- Задавай напрямую через `AskUserQuestion` ДО начала генерации
- Группируй связанные вопросы в один вызов (макс. 4 вопроса за раз)
- Если уточнения по задаче уже пройдены ранее в этом разговоре (контекст собран из трекера, вопросы заданы) — переходи к генерации без повторных вопросов

**Для аналитика** — требуют бизнес-контекста, недоступного пользователю в чате (точные тексты ошибок из API, тайминги, политики, особенности интеграций):
- Собирай в отдельный список «Вопросы для аналитика» в конце ответа
- После того как пользователь принесёт ответы — актуализируй ТК

12. Оценка полноты покрытия:
   - В конце дай краткую оценку: что покрыто, что осознанно не покрыто и почему

13. Прямое создание в TMS через MCP (если подключён):
   - **Границы.** Если проект в TMS общий для нескольких команд — все операции
     только внутри дерева папок своей команды; чужие корни не менять и не
     выводить в отчёты. Зафиксируйте свою корневую папку в `CLAUDE.md` проекта.
   - Перед созданием ВСЕГДА получай актуальное дерево папок (`get_folders`
     или аналог) — структура живая, подпапки добавляются; не работай по
     снимку из памяти.
   - Перед генерацией новых ТК сверь существующее покрытие целевой папки
     (поиск ТК по папке): генерируй только недостающее; пересечение
     с существующим ТК — повод актуализировать его через update,
     а не создавать дубликат.
   - Пути папок использовать ДОСЛОВНО как вернул API: имена могут содержать
     трейлинг-пробелы. При создании новых папок избегать спецсимволов
     (кавычки, запятые) и смешения алфавитов в именах — они часто ломают
     поиск по API.
   - Папку выбирай по функционалу фичи; для новой фичи без своей подпапки —
     предложи создать папку или уточни у пользователя.
   - Правила контента те же, что для CSV: 1 шаг = 1 description,
     expectedResult после значимых шагов (правила выше); ОР формулировать
     «Система отображает…».
   - Привязывай ТК к тикету трекера (issue_links или аналог) — всегда,
     если TMS это поддерживает.
   - Учитывай, что TMS может перезаписывать статус при создании (напр. всегда
     «Draft»); перевод в «Approved» — после ревью и ответов аналитика через update.
   - md-файл с ТК остаётся обязательным этапом валидации ДО создания в TMS;
     CSV (раздел 10) — fallback, если MCP недоступен.
   - Прогоны по задаче (по запросу пользователя): создать test run → статусы
     по ходу прогона (Pass/Fail/Blocked). Статус Fail сопровождай комментарием
     с причиной/ссылкой на дефект.
   - **Точка входа — первым шагом ТК открывать страницу объекта проверки**
     («Открыть страницу по URL …»), чтобы было видно где проверять. Для ТК
     с особым предусловием (экран успеха, заполненная форма) URL указывать
     в precondition.
   - Если TMS рендерит описания как HTML (напр. Zephyr Scale DC) — URL
     оформлять кликабельной ссылкой `<a href="https://...">https://...</a>`,
     чтобы ссылка в ТК была кликабельна.

14. Параллельное исполнение через субагентов (окупается от ~10 ТК):

   **Делегировать — механику, где текст уже готов:**
   - **Чтение больших выгрузок.** Когда выгрузка макета или API не влезает в ответ
     инструмента и падает в файл, не грепать её выборочно: пропустишь целые фреймы.
     На каждый узел свой субагент с явным заданием — «прочитать файл ЦЕЛИКОМ чанками
     по ~160 строк через offset/limit, вернуть полный список элементов с ДОСЛОВНЫМИ
     текстами, размеры, отступы, состояния компонентов и аннотации дизайнера».
     Все узлы — параллельно.
   - **Заливка ТК в TMS** по согласованному md-файлу: 6-8 ТК на субагента,
     около 4 субагентов разом.
   - **Массовая смена статусов** (Draft → Approved после ревью) и **простановка
     результатов прогона**: список ключей делится между субагентами.
   - **Массовые правки текстов уже созданных ТК** (опечатки, смена формулировок,
     актуализация ОР после ответов аналитика): список ключей делится между 3-4 субагентами.

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

   **Промпт субагента-заливщика — обязательный минимум:**
   - дословный шаблон вызова с уже подставленными ключом проекта, путём папки
     (скопировать из API папок буква в букву), кастомными полями, привязкой
     к тикету и приоритетом;
   - **«HTML-ссылку вставлять реальным тегом `<a href="...">...</a>`, НЕ экранировать
     в `&lt;a&gt;`»** — иначе TMS покажет тег обычным текстом;
   - «текст ТК не переписывать, не сокращать и не улучшать — переносить дословно
     из md-файла»;
   - «если вызов создания вернул ошибку или неясный результат — НЕ повторять его
     (риск дубля), вернуть ключ как проблемный»;
   - вернуть список созданных ключей в порядке ТК.

   **Промпт субагента-правщика (правка уже созданных ТК) — обязательный минимум:**
   - точный список ключей этого субагента и запрет открывать любые другие: в диапазоне
     ключей регулярно попадаются ТК других команд;
   - **«шаги, полученные при чтении ТК, ОТСОРТИРОВАТЬ по `index` перед отправкой»** —
     API отдаёт их в произвольном порядке, без сортировки сценарий перемешается;
   - **«вызов обновления заменяет скрипт ТК целиком»** — переносить ВСЕ шаги дословно,
     меняя только оговорённые подстроки;
   - название, цель и предусловие передавать, только если правка коснулась именно их;
     приоритет, статус, папку, привязку к тикету и кастомные поля НЕ передавать —
     непереданные поля остаются прежними;
   - «HTML-ссылку вставлять реальным тегом `<a href="...">...</a>`, НЕ экранировать»;
   - «совпадений в ТК нет — вызов обновления не делать вообще»;
   - «при ошибке или неясном результате НЕ повторять вызов»;
   - вернуть по каждому ключу строку: изменено (какие поля и шаги) | без изменений | ОШИБКА.

   **Сверка после заливки обязательна и делается лично, не субагентом:**
   поиск ТК по папке (количество, приоритеты, тип) плюс чтение 1-2 ТК целиком
   (ссылка отрендерилась тегом, шаги на месте, привязка к тикету проставлена).
   Отчёт субагента «всё создал» доказательством не считается.

   **После массовой правки сверка тоже личная и сплошная:** прочитать КАЖДЫЙ изменённый
   ТК — новые формулировки на месте, старых не осталось, индексы шагов идут сплошняком
   0..N в логике сценария, ссылки остались тегами, привязка к тикету и тип не сброшены.