akovalion Составь тест-кейсы по правилам ниже. Сначала готовь их в md-файле для валидации, затем — CSV для импорта (или прямое создание через MCP, раздел 13).
Учитывай логику требований и существующие макеты. При расхождении между макетом и реализацией — фиксируй вопросом аналитику.
Полнота источников и честность ограничений:
- Перед генерацией собери ВСЕ источники и держи их статус явно. В итоговом отчёте приведи таблицу источников: тикет / вложения тикета / связанные задачи / вики (Confluence) / выгрузка Figma / визуальный просмотр ВСЕХ фреймов / комментарии Figma / реализация (если есть) — по каждому: изучен | не изучен | чем заблокирован. «Не изучен» без причины и плана обхода — недопустимое состояние отчёта.
- Упёрся в ограничение инструмента (обрезанный ответ MCP, недоступный файл, упавший
субагент) — НЕ деградируй молча: сразу сообщи пользователю и предложи обход.
Типовой пример: вложения тикета через MCP трекера обрезаются по размеру ответа —
те же файлы часто лежат на связанных страницах вики, откуда их можно скачать
инструментом, сохраняющим файл на диск целиком (для Confluence —
confluence_download_attachment). - Самоотчёт субагента («прочитал всё, пропусков нет») — не доказательство: факты, на которых строятся ОР (тексты, состав полей, лейблы, ЧИСЛА — размеры, отступы, gap), перепроверяй точечно по первоисточнику (визуал фрейма, файл, живая система).
- Комментарии Figma через MCP недоступны (
get_figma_dataих не отдаёт): ДО генерации ТК явно запроси у пользователя комментарии из макета (текстом или скриншотами) — в них часто живут правки поверх макета (тексты ошибок, убранные поля, финальные формулировки). Пока комментариев нет — источник числится незакрытым, об этом сказано в отчёте. - Если скоуп задан текстом ТЗ — каждый ТК привязывай к конкретному пункту ТЗ (колонка «пункт ТЗ» в таблице покрытия). Проверка, порождённая только макетом или эвристикой, в ТК не превращается — она идёт в «Вопросы аналитику» / «наблюдения вне ТЗ». Макет — источник точных значений для пунктов ТЗ, не генератор новых проверок.
Формат тест-кейсов:
- Наименование — короткое и понятное (объект: суть проверки, как «Открытие календаря», «Пагинация списка»). Без URL, селекторов и технических деталей в названии (им место в шагах/objective). Не пиши в названии TC-(номер ТК).
- Предусловия выполнения тест-кейса (если применимо)
- Шаги (максимально подробные, атомарные)
- Ожидаемый результат (указывай только после логически значимых шагов)
- Приоритет (High / Normal / Low)
- Тип (UI / Functionality / Integration — или значения, принятые в вашем проекте)
- Reference (ссылка или название макета из Figma/PDF, конкретный элемент) - если применимо
- Использовать ТОЧНЫЕ названия полей, кнопок, заголовков, плейсхолдеров как в реализации/макетах/ТЗ
- Если в макете поле называется «Кем выдан?» — писать «Кем выдан?», не «Кем выдан ДУЛ»
- Проверять: двоеточия, вопросительные знаки, регистр, пробелы в лейблах
- Если названия в требованиях и макетах расходятся — фиксировать как вопрос для аналитика
Шаги:
- Каждый шаг — одно действие
- Обязательно указывать: • "Кликнуть по кнопке «Название кнопки»" • "Ввести значение «…» в поле «Название поля»" • "Выбрать значение «…» из выпадающего списка «Название»" • "Навести курсор на элемент «…»" • "Открыть страницу по URL …"
- Избегай ссылок-сокращений: ❌ «аналогично», «повторить шаги», «как в предыдущем тест-кейсе», ❌ «выбрать значения согласно названию ТК» Каждый шаг должен читаться независимо от других ТК.
Ожидаемый результат:
- По умолчанию — отдельный Expected Result после значимых шагов, а не один общий в конце
- Указывай результат после шагов, где: • происходит валидация • меняется состояние UI • отправляются данные • отображается ошибка/сообщение и тд
- Формулировка: • "Система отображает…" • "Поле подсвечивается ошибкой…" • "Кнопка становится активной/неактивной…" и тд
- Источник ОР — требования/ТЗ, затем макеты. Реализация/стенд — НЕ источник ОР: из реализации берутся только точные названия элементов, а ожидаемое ПОВЕДЕНИЕ — из требований и макетов. Если реализация расходится с требованиями — это баг или вопрос аналитику, а не основа для ОР.
- ЗАПРЕЩЕНЫ в ТК формулировки «зафиксировать на прогоне», «уточнить по факту реализации», «сверить с реализацией»: они превращают тестирование в документирование того, что сделали. Неизвестный текст/поведение — это вопрос аналитику ДО прогона (раздел 11); в ОР — наблюдаемый ожидаемый смысл. Единственное исключение — снятие эталона с работающей PROD-реализации того же требования (например, текст той же валидации на действующей форме), когда аналитик явно подтвердил «требование то же».
Покрытие: Негатив — обязательный артефакт, не опция. Выдели отдельную группу «Негатив/Границы»; в оценке покрытия (раздел 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-элементы (кнопка «Нет отчества», тогл, иконка очистки) - проверять их наличие/отсутствие и поведение отдельно
Сверка с реализацией и макетами:
- При наличии макетов/скриншотов — сверять тест-кейсы с ними
- 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 с макетом (точные заголовки, тексты, полный состав списков/групп, названия, иконки) — дефолт максимальной точности. Послабление по контенту — ТОЛЬКО когда пользователь явно просит не привязываться к контенту (напр. наполнение тестового стенда отличается от макета): тогда проверять наличие блока и ключевые названия/заголовки/иконки, не впечатывая жёсткий полный перечень. Структуру, заголовки и ключевые названия сверять точно всегда
- Расхождения фиксировать как баги или вопросы
- Если поле по требованиям «необязательное», но в реализации требует ввода — это баг
Интеграции: Если есть API / внешние сервисы:
- Проверять: • корректную отправку параметров • обработку ошибок 4xx / 5xx • отсутствие падений UI и тд
- Указывать это в шагах и Expected Result
Структура:
- Порядок ТК: сначала High, затем Normal, затем Low
- Внутри каждой группы сначала позитивные сценарии, затем негативные
- Группируй логически (Отображение / Валидация / Навигация / Негатив)
- Разделяй Desktop и Mobile, если есть адаптив
- Целевые браузеры — по требованиям проекта; типовой минимум: Chrome (Desktop + Android), Safari (iOS)
- Для Mobile-only ТК добавляй префикс
[Mobile]в название
Стиль:
- Деловой, QA-стиль
- Без воды
- Четко, однозначно, воспроизводимо
Результат:
- Тест-кейсы должны быть готовы к импорту в 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). Сохранять в текущую рабочую директорию.
Экспорт для 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 (писать текстом)
- Анализ требований и уточнения
Различай два типа вопросов по неоднозначностям:
Критичные для генерации — без ответа невозможно корректно составить ТК (противоречие в макете и описании, неясный happy path, неизвестное поведение валидации, отсутствует ключевой сценарий):
- Задавай напрямую через
AskUserQuestionДО начала генерации - Группируй связанные вопросы в один вызов (макс. 4 вопроса за раз)
- Если уточнения по задаче уже пройдены ранее в этом разговоре (контекст собран из трекера, вопросы заданы) — переходи к генерации без повторных вопросов
Для аналитика — требуют бизнес-контекста, недоступного пользователю в чате (точные тексты ошибок из API, тайминги, политики, особенности интеграций):
- Собирай в отдельный список «Вопросы для аналитика» в конце ответа
- После того как пользователь принесёт ответы — актуализируй ТК
- Оценка полноты покрытия:
- В конце дай краткую оценку: что покрыто, что осознанно не покрыто и почему
- Прямое создание в 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
оформлять кликабельной ссылкой
<a href="https://...">https://...</a>, чтобы ссылка в ТК была кликабельна.
- Параллельное исполнение через субагентов (окупается от ~10 ТК):
Делегировать — механику, где текст уже готов:
- Чтение больших выгрузок. Когда выгрузка макета или API не влезает в ответ инструмента и падает в файл, не грепать её выборочно: пропустишь целые фреймы. На каждый узел свой субагент с явным заданием — «прочитать файл ЦЕЛИКОМ чанками по ~160 строк через offset/limit, вернуть полный список элементов с ДОСЛОВНЫМИ текстами, размеры, отступы, состояния компонентов и аннотации дизайнера». Все узлы — параллельно.
- Заливка ТК в TMS по согласованному md-файлу: 6-8 ТК на субагента, около 4 субагентов разом.
- Массовая смена статусов (Draft → Approved после ревью) и простановка результатов прогона: список ключей делится между субагентами.
- Массовые правки текстов уже созданных ТК (опечатки, смена формулировок, актуализация ОР после ответов аналитика): список ключей делится между 3-4 субагентами.
Не делегировать — здесь цена ошибки выше выигрыша в скорости:
- формулировки названий, шагов и ожидаемых результатов: единый стиль и точность важнее скорости;
- выбор папки, решение о создании раздела, состав вопросов аналитику;
- финальную сверку.
Промпт субагента-заливщика — обязательный минимум:
- дословный шаблон вызова с уже подставленными ключом проекта, путём папки (скопировать из API папок буква в букву), кастомными полями, привязкой к тикету и приоритетом;
- «HTML-ссылку вставлять реальным тегом
<a href="...">...</a>, НЕ экранировать в<a>» — иначе TMS покажет тег обычным текстом; - «текст ТК не переписывать, не сокращать и не улучшать — переносить дословно из md-файла»;
- «если вызов создания вернул ошибку или неясный результат — НЕ повторять его (риск дубля), вернуть ключ как проблемный»;
- вернуть список созданных ключей в порядке ТК.
Промпт субагента-правщика (правка уже созданных ТК) — обязательный минимум:
- точный список ключей этого субагента и запрет открывать любые другие: в диапазоне ключей регулярно попадаются ТК других команд;
- «шаги, полученные при чтении ТК, ОТСОРТИРОВАТЬ по
indexперед отправкой» — API отдаёт их в произвольном порядке, без сортировки сценарий перемешается; - «вызов обновления заменяет скрипт ТК целиком» — переносить ВСЕ шаги дословно, меняя только оговорённые подстроки;
- название, цель и предусловие передавать, только если правка коснулась именно их; приоритет, статус, папку, привязку к тикету и кастомные поля НЕ передавать — непереданные поля остаются прежними;
- «HTML-ссылку вставлять реальным тегом
<a href="...">...</a>, НЕ экранировать»; - «совпадений в ТК нет — вызов обновления не делать вообще»;
- «при ошибке или неясном результате НЕ повторять вызов»;
- вернуть по каждому ключу строку: изменено (какие поля и шаги) | без изменений | ОШИБКА.
Сверка после заливки обязательна и делается лично, не субагентом: поиск ТК по папке (количество, приоритеты, тип) плюс чтение 1-2 ТК целиком (ссылка отрендерилась тегом, шаги на месте, привязка к тикету проставлена). Отчёт субагента «всё создал» доказательством не считается.
После массовой правки сверка тоже личная и сплошная: прочитать КАЖДЫЙ изменённый ТК — новые формулировки на месте, старых не осталось, индексы шагов идут сплошняком 0..N в логике сценария, ссылки остались тегами, привязка к тикету и тип не сброшены.