test-cases

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

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

1. Полнота источников и честность ограничений:

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

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

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

3. Шаги:

   • Каждый шаг — одно действие
   • Обязательно указывать: • "Кликнуть по кнопке «Название кнопки»" • "Ввести значение «…» в поле «Название поля»" • "Выбрать значение «…» из выпадающего списка «Название»" • "Навести курсор на элемент «…»" • "Открыть страницу по URL …"
   • Избегай ссылок-сокращений: ❌ «аналогично», «повторить шаги», «как в предыдущем тест-кейсе», ❌ «выбрать значения согласно названию ТК» Каждый шаг должен читаться независимо от других ТК.
   • Всё, что тестировщик копирует, - в Test Data шага (testData), готовым к вставке: • GET-запрос - полной ссылкой, которая открывается в браузере. GraphQL тоже принимает GET: https://…/graphql?query= + запрос через encodeURIComponent. Нечитаемую закодированную ссылку - коротким текстом ссылки («GraphQL - поля элемента 123»), полный URL только в href; • POST/PUT - curl -i одной строкой (без -i статус в выводе не виден, а ОР его требует): полный URL, нужные заголовки, тело (-F для multipart, --form-string для JSON-строки в поле multipart, -H 'Content-Type: application/json' -d '…' для JSON); уникальный email - через $(date +%s) прямо в curl; цепочку запросов - через переменную в том же терминале; граничную длину - через printf ('$(printf '%0101d' 0 | tr 0 A)' - 101 буква A), а не рядом из 101 символа: такой ряд ошибается на единицу при переносе, а граница перестаёт проверяться; • значения полей формы - строками «Поле: значение» через <br />; • сниппет для Console DevTools - одной строкой, его результат - в ОР. Тяжёлый ответ или проверка по всему списку - сниппет на открытой ссылке, который сам выдаёт итог: fetch(location.href).then(r=>r.json()).then(d=>…). В description остаётся действие: «Отправить запрос из Test Data в терминале», «Открыть ссылку из Test Data, найти code из шага 1 (Ctrl+F)». Запрос, пересказанный прозой («POST … с телом: userName 'Тест', …»), и запрос без самого запроса («запросить в GraphQL элемент») запрещены.
   • Заполнение формы набором значений из Test Data - один шаг. Отдельные шаги «Выбрать регион», «Отметить чекбокс» с ОР «Регион выбран» не плодить.
   • Запрос или отправка формы создаёт реальную запись на проде (заявка, обращение, письмо, событие) - одна строка в предусловии: «PROD. Запрос создаёт реальную заявку в CRM.»