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

3. Шаги:

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

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

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