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).

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

1. Формат тест-кейсов:

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

2. Шаги:

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

3. Ожидаемый результат:

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

4. Покрытие: Негатив — обязательный артефакт, не опция. Выдели отдельную группу «Негатив/Границы»; в оценке покрытия (раздел 12) перечисли, какие негатив-классы закрыты и какие осознанно пропущены (с причиной). Позитив-only набор неполон, даже если объект кажется простым/навигационным. Оверлеи/модалки/панели (пример пака под тип объекта): блокировка прокрутки (позиция сохраняется, фон не скроллится, компенсация ширины скроллбара без «прыжка»), закрытие ×/Esc/клик по фону/Back, deep-link и перезагрузка (состояние в URL), даблклик/спам, ресайз при открытом, стекинг оверлеев, вмещаемость во вьюпорт на КАЖДОМ брейкпоинте (вкл. планшет и короткий/ландшафтный экран): контент не обрезается по вертикали И по горизонтали (не уезжает за края), при контенте выше вьюпорта — внутренний скролл, все элементы и кнопки (submit/футер/закрытие) доступны, безопасные отступы от краёв. У других типов объектов — свой негатив-пак (формы, списки, навигация, API; см. references). Включай в покрытие:

   • Позитивные сценарии
   • Негативные сценарии
   • Граничные значения Не дублируй одинаковые проверки без причины.
   • UI-состояния: • default • hover • focus • disabled • error • loading (если применимо) и тд
   • Поведение при: • перезагрузке страницы • навигации • потере сети (если есть интеграции) и тд
   • Должна быть качественная оптимизация, но не терять качество и покрытие
   • Проверки производятся на разрешениях (если задача связана с UI/адаптивом): Desktop: 1920x1080, 1536x864, 2560x1440 Mobile: 414x896, 360x800, 393x873, 430x926 Tablet: 768x1024, 1024x768
   • Целостность вёрстки на КАЖДОМ брейкпоинте — для ЛЮБОГО объекта, не только модалок: ничего не обрезается по вертикали и по горизонтали и не уезжает за края; все элементы, тексты, иконки и кнопки видимы и доступны; при контенте выше вьюпорта — скролл (для оверлеев внутренний); состав и расположение сверяются с макетом ИМЕННО для этого брейкпоинта (пункт не должен пропасть, переехать или сменить сторону иконки). Модалки/оверлеи — лишь частный случай.
   • Повторное использование формы: • работоспособность после успешной отправки и возврата (кнопка «Отправить ещё» и т.п.) • корректность всех полей и списков при повторном заполнении
   • Последовательная валидация: • смена типа ошибки при изменении ввода (например: ввод латиницы → стирание → ошибка должна смениться с «Только кириллица» на «Обязательное поле») • независимость ошибок между полями (ошибка в поле А не влияет на текст ошибки в поле Б)
   • Точные тексты ошибок: • указывать ожидаемый текст ошибки в Expected Result, а не абстрактное «отображается ошибка» Если текст ошибки неизвестен - указывать ожидаемый смысл
   • Если поле имеет дополнительные UI-элементы (кнопка «Нет отчества», тогл, иконка очистки) - проверять их наличие/отсутствие и поведение отдельно

5. Сверка с реализацией и макетами:

   • При наличии макетов/скриншотов — сверять тест-кейсы с ними
   • Figma — ОБЯЗАТЕЛЬНО смотреть макет ГЛАЗАМИ, а не только его структуру: выгрузка дерева (get_figma_data) даёт сетку и layout текстом, но часть контента скрыта в шаблонах компонентов (template=…) и в выгрузку не попадает; различия между брейкпоинтами (desktop/mobile) в дереве не видны. Дополнительно скачивать отрисованные фреймы (download_figma_images, desktop + mobile) и просматривать их — только визуал даёт точные подписи кнопок/карточек, полный состав групп и ловит расхождения между брейкпоинтами
   • По умолчанию ОР пишутся 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>, чтобы ссылка в ТК была кликабельна.