# Test Cases
> Составление тест-кейсов по best practice QA с экспортом в CSV для импорта в Zephyr Scale (Option 1) или созданием напрямую через MCP вашей TMS. Используй, когда пользователь просит сгенерировать, составить или подготовить тест-кейсы, чек-листы или CSV для импорта в TMS.
- Skill: `akovalion/test-cases-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add akovalion/test-cases-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/akovalion/test-cases-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: akovalion (https://skillmd.com/u/akovalion)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/akovalion/test-cases-2
---
Составь тест-кейсы по правилам ниже. Сначала готовь их в 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 набор неполон, даже если объект кажется простым/навигационным.
**Эвристика ≠ требование.** Проверка из негатив/оверлей-пака, у которой нет опоры в ТЗ/макете (закрытие попапа, курсор, анти-спам и т.п.), в ТК помечается источником «эвристика», а её ОР формулируется как наблюдаемое ожидание. Fail такой проверки — вопрос аналитику, не дефект задачи; в дефект он превращается только после подтверждения требования. Это уточнение правила «скоуп = ТЗ» из раздела 0, не отмена негатив-пака.
**Оверлеи/модалки/панели (пример пака под тип объекта):** блокировка прокрутки (позиция сохраняется, фон не скроллится, компенсация ширины скроллбара без «прыжка»), закрытие ×/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 и ссылки на дефекты отдавай в чат/отчёт. После серии статусов сверь
итог с execution summary прогона в TMS, а не пересчитывай вручную.
- **Точка входа — первым шагом ТК открывать страницу объекта проверки**
(«Открыть страницу по URL …»), чтобы было видно где проверять. Для ТК
с особым предусловием (экран успеха, заполненная форма) URL указывать
в precondition.
- Если TMS рендерит описания как HTML (напр. Zephyr Scale DC) — URL
оформлять кликабельной ссылкой `https://...`,
чтобы ссылка в ТК была кликабельна.
14. Параллельное исполнение через субагентов (окупается от ~10 ТК):
**Делегировать — механику, где текст уже готов:**
- **Чтение больших выгрузок.** Когда выгрузка макета или API не влезает в ответ
инструмента и падает в файл, не грепать её выборочно: пропустишь целые фреймы.
На каждый узел свой субагент с явным заданием — «прочитать файл ЦЕЛИКОМ чанками
по ~160 строк через offset/limit, вернуть полный список элементов с ДОСЛОВНЫМИ
текстами, размеры, отступы, состояния компонентов и аннотации дизайнера».
Все узлы — параллельно.
- **Заливка ТК в TMS** по согласованному md-файлу: 6-8 ТК на субагента,
около 4 субагентов разом.
- **Массовая смена статусов** (Draft → Approved после ревью) и **простановка
результатов прогона**: список ключей делится между субагентами.
- **Массовые правки текстов уже созданных ТК** (опечатки, смена формулировок,
актуализация ОР после ответов аналитика): список ключей делится между 3-4 субагентами.
**Не делегировать — здесь цена ошибки выше выигрыша в скорости:**
- формулировки названий, шагов и ожидаемых результатов: единый стиль
и точность важнее скорости;
- выбор папки, решение о создании раздела, состав вопросов аналитику;
- финальную сверку.
**Промпт субагента-заливщика — обязательный минимум:**
- дословный шаблон вызова с уже подставленными ключом проекта, путём папки
(скопировать из API папок буква в букву), кастомными полями, привязкой
к тикету и приоритетом;
- **«HTML-ссылку вставлять реальным тегом `...`, НЕ экранировать
в `<a>`»** — иначе TMS покажет тег обычным текстом;
- «текст ТК не переписывать, не сокращать и не улучшать — переносить дословно
из md-файла»;
- «если вызов создания вернул ошибку или неясный результат — НЕ повторять его
(риск дубля), вернуть ключ как проблемный»;
- вернуть список созданных ключей в порядке ТК.
**Промпт субагента-правщика (правка уже созданных ТК) — обязательный минимум:**
- точный список ключей этого субагента и запрет открывать любые другие: в диапазоне
ключей регулярно попадаются ТК других команд;
- **«шаги, полученные при чтении ТК, ОТСОРТИРОВАТЬ по `index` перед отправкой»** —
API отдаёт их в произвольном порядке, без сортировки сценарий перемешается;
- **«вызов обновления заменяет скрипт ТК целиком»** — переносить ВСЕ шаги дословно,
меняя только оговорённые подстроки;
- название, цель и предусловие передавать, только если правка коснулась именно их;
приоритет, статус, папку, привязку к тикету и кастомные поля НЕ передавать —
непереданные поля остаются прежними;
- «HTML-ссылку вставлять реальным тегом `...`, НЕ экранировать»;
- «совпадений в ТК нет — вызов обновления не делать вообще»;
- «при ошибке или неясном результате НЕ повторять вызов»;
- вернуть по каждому ключу строку: изменено (какие поля и шаги) | без изменений | ОШИБКА.
**Сверка после заливки обязательна и делается лично, не субагентом:**
поиск ТК по папке (количество, приоритеты, тип) плюс чтение 1-2 ТК целиком
(ссылка отрендерилась тегом, шаги на месте, привязка к тикету проставлена).
Отчёт субагента «всё создал» доказательством не считается.
**После массовой правки сверка тоже личная и сплошная:** прочитать КАЖДЫЙ изменённый
ТК — новые формулировки на месте, старых не осталось, индексы шагов идут сплошняком
0..N в логике сценария, ссылки остались тегами, привязка к тикету и тип не сброшены.