ИИ в QA: анализ требований, тест-дизайн и генерация импорта в Zephyr

Роль ИИ в QA: границы применения, качество и контроль результата

Что в этом курсе считается ИИ

В контексте курса под ИИ мы будем понимать в первую очередь большие языковые модели (LLM) — системы, которые по входному тексту (контексту) генерируют продолжение: ответы, списки, таблицы, черновики требований, тест-кейсы, форматы для импорта. Это не «магический тестировщик», а инструмент, который:

быстро обрабатывает и переформулирует текст;

помогает расширять варианты проверок и формулировок;

ускоряет рутинные операции (черновики артефактов, форматирование, консолидация).

Ключевое ограничение: LLM не знает ваш продукт. Она статистически предсказывает правдоподобный текст на основе данных обучения и контекста запроса.

Роль QA при использовании ИИ

Роль тестировщика не исчезает, а меняется: QA становится владельцем качества входных данных, промпта, критериев приемки результата ИИ и финальной валидации артефактов.

Удобная модель мышления:

ИИ = стажёр, который быстро делает черновик.

QA = ответственный инженер, который задаёт рамки, проверяет, исправляет, принимает решение.

Практическое правило: если вы не можете объяснить, почему артефакт корректен, значит он ещё не готов — даже если его «красиво написал ИИ».

Где ИИ реально полезен в QA-процессе

В рамках курса мы будем применять ИИ в задачах, где результат можно объективно проверить по требованиям, доменным правилам и форматам артефактов.

Основные сценарии:

Анализ требований

1. Выделение акторов, бизнес-правил, ограничений. 2. Поиск неоднозначностей, противоречий, пропусков. 3. Приведение требований к тестопригодному виду (черновик).

Тест-дизайн

1. Генерация вариантов проверок по техникам: классы эквивалентности, граничные значения, таблицы решений, переходы состояний. 2. Подсказки по рискам и негативным сценариям. 3. Грубая оценка покрытия.

Тестовая документация

1. Черновики чек-листов и тест-кейсов. 2. Нормализация формулировок: шаги, ожидаемые результаты, предусловия. 3. Генерация структурированных форматов (включая CSV для импорта в Zephyr).

Справочные материалы по инструменту (для следующих модулей):

Zephyr Scale Cloud Documentation

Границы применения: что нельзя делегировать ИИ

Ниже — зоны, где ИИ может помочь только как источник идей, но не как авторитет.

Ответственность и решение о качестве

1. Решение «можно релизить или нет» принимает команда по своим процессам. 2. Приоритизация рисков и определение достаточности покрытия — ответственность QA и команды.

Доменная корректность без подтверждения

1. В финансовых, медицинских, юридических сценариях ошибки в терминах и правилах критичны. 2. Любое доменное утверждение ИИ должно подтверждаться источником: требованиями, аналитикой, SME.

Работа с конфиденциальными данными

1. Нельзя отправлять в публичные модели персональные данные, коммерческую тайну, секреты (токены, ключи, пароли), внутренние логи с идентификаторами. 2. Допустимый подход — маскирование и синтетические данные.

Автоматическое выполнение действий в продуктиве

1. ИИ может предложить команду, SQL, скрипт, но запуск — только после ревью и в безопасной среде.

Ориентир по управлению рисками ИИ (как общая рамка):

NIST AI Risk Management Framework

Типовые ошибки ИИ в QA-артефактах

ИИ часто ошибается не «случайно», а предсказуемо. Эти паттерны важно научиться распознавать.

| Ошибка | Как проявляется в тест-артефактах | Чем опасно | Как контролировать | |---|---|---|---| | Галлюцинации | «Придумал» поля, экраны, статусы, API | Ложные тесты, потеря времени | Требовать список допущений и сверять с источником | | Подмена контекста | Перепутал платформу, роль пользователя, версию | Неприменимые проверки | Жёстко фиксировать контекст и ограничения в промпте | | Неполное покрытие | Пропускает негативные кейсы и границы | Пропуск дефектов | Явно требовать техники тест-дизайна и минимальные наборы | | Слабые ожидаемые результаты | «Должно успешно сохраниться» без критериев | Невоспроизводимость | Требовать проверяемые expected results (сообщения, поля, статусы) | | Нарушение форматов | CSV не соответствует полям Zephyr, ломает импорт | Трудозатраты на правки | Задавать формат строго и валидировать на примерах | | Самоуверенный тон | Звучит убедительно, но неверно | Ошибки проходят незамеченными | Принцип: доверяй, но проверяй по требованиям |

Если вы видите уверенную формулировку без опоры на требования — это красный флаг.

Контур контроля качества результата ИИ

Чтобы ИИ реально повышал качество, нужен процесс проверки, похожий на тестирование требований.

!Контур контроля качества: от входных данных и промпта до валидации и принятого артефакта

Практический чек-лист валидации (применим к требованиям, чек-листам, тест-кейсам, CSV):

Трассируемость

1. Можно ли привязать каждый тест к конкретному требованию/правилу? 2. Нет ли тестов «в вакууме», которые не покрывают заявленную функциональность?

Корректность по источнику

1. Нет ли добавленных сущностей (поля, кнопки, роли), которых нет в требованиях? 2. Все ли бизнес-правила отражены без искажений?

Проверяемость

1. Ожидаемый результат измерим: конкретное сообщение, изменение состояния, записанные значения. 2. Исключены формулировки «должно работать», «успешно», «корректно» без критериев.

Полнота покрытия по техникам

1. Есть позитивные и негативные сценарии. 2. Для правил с диапазонами — границы и близкие к границам значения. 3. Для комбинаций условий — таблица решений или эквивалент.

Непротиворечивость и консистентность

1. Единые термины, статусы, форматы дат/валют. 2. Нет кейсов, которые конфликтуют друг с другом по ожидаемому результату.

Соответствие формату хранения

1. Поля Zephyr заполнены так, как требуется импорту. 2. Нет лишних столбцов/неверных разделителей/переносов строк в критичных местах.

Как задавать промпт, чтобы результат был управляемым

Хороший промпт для QA — это не «сгенерируй тест-кейсы», а постановка задачи с критериями, ограничениями и форматом.

Минимальная структура промпта:

Роль

1. Кем должен быть ИИ: например, Senior QA, аналитик требований.

Контекст

1. Продукт, платформа, актор, цель фичи.

Источник правды

1. Что считать приоритетным: требования ниже, макеты, бизнес-правила.

Ограничения

1. Запрет на домыслы: если данных нет — пометить как допущение или вопрос.

Техника/подход

1. Какие техники тест-дизайна применить и где.

Формат вывода

1. Таблица, список, поля Zephyr, строгие заголовки.

Пример плохого промпта

Сделай тест-кейсы для логина.

Почему плохо:

не задан контекст (веб/мобайл, роли, ограничения);

нет требований к покрытию;

нет формата и критериев качества;

ИИ неизбежно начнёт «додумывать».

Пример хорошего промпта (шаблон)

Что даёт такой промпт:

ИИ ограничен источником;

покрытие задано через техники;

ожидаемый формат упрощает проверку и дальнейший импорт.

Как ловить ошибки ИИ: практические приёмы контроля

Ниже — способы не верить на слово и быстро повышать качество результата.

Принудительная явность допущений

1. Просите отдельный блок Допущения и Вопросы. 2. Любая «придуманная» часть должна всплыть там.

Двойная проверка ожидаемых результатов

1. Для каждого теста задайте себе вопрос: как именно я пойму, что тест прошёл? 2. Если ответа нет — expected result нужно уточнить.

Негативные сценарии как обязательная квота

1. Требуйте минимум N негативных тестов на каждый бизнес-правил. 2. ИИ часто склоняется к позитивным сценариям.

Анти-паттерн «проверить всё»

1. Если ИИ выдаёт 200 тестов без структуры — это шум. 2. Требуйте группировку по правилам/экранам/рискам и минимальный достаточный набор.

Проверка на формат и импорт

1. Чем раньше вы фиксируете формат (например, под Zephyr), тем меньше ручных правок.

Ресурс по типовым рискам LLM (полезно для мышления о уязвимостях и ошибках):

OWASP Top 10 for Large Language Model Applications

Политика данных: что можно и что нельзя отправлять в ИИ

Для курса используйте правило минимизации данных: отправляйте ровно то, что нужно для решения задачи.

Разрешено (при отсутствии внутренних запретов компании):

обезличенные требования и пользовательские истории;

синтетические тестовые данные;

публичные спецификации и общие примеры.

Запрещено:

персональные данные (ФИО, телефоны, email реальных клиентов), финансовые реквизиты;

секреты доступа: токены, ключи, пароли;

внутренние логи/дампы, содержащие идентификаторы пользователей или структуру инфраструктуры.

Если нельзя передать реальный артефакт, заменяйте:

имена и ID на USER_001, ORDER_123;

домены на example.test;

значения на диапазоны и классы эквивалентности.

Итоги урока

После этого урока у вас должна закрепиться базовая установка курса:

ИИ ускоряет подготовку QA-артефактов, но повышает требования к валидации.

Качество результата определяется не красотой текста, а проверяемостью, трассируемостью и покрытием по техникам.

Контроль начинается с корректного контекста и строгого формата, а заканчивается ревью QA и фиксацией принятого артефакта.

В следующих уроках мы начнём применять этот подход на требованиях: научимся превращать «сырой текст» в тестопригодные правила и дальше — в тест-дизайн и артефакты под Zephyr.

Анализ требований с ИИ: неоднозначности, критерии приемки, риски

Зачем QA анализирует требования до тест-дизайна

В предыдущей статье мы зафиксировали базовую позицию курса: ИИ — это стажёр, который ускоряет подготовку черновиков, а QA отвечает за качество входных данных, промпта и финальную валидацию.

Анализ требований — первая точка, где ИИ даёт максимальный эффект: он быстро находит неоднозначности, пропуски и противоречия. Но именно здесь выше риск галлюцинаций: модель начнёт «додумывать» бизнес-правила и интерфейсы, которых нет в тексте.

Цель этого урока: научиться использовать ИИ так, чтобы на выходе получались тестопригодные требования, критерии приемки и список рисков, а не «красивый пересказ».

Что такое тестопригодное требование

Тестопригодное требование — это требование, для которого можно однозначно:

понять что должно произойти;

определить входы и условия;

наблюдать результат и сравнить его с ожидаемым;

установить границы (диапазоны, лимиты, состояния);

связать проверки с источником (трассируемость).

Если требование нельзя проверить без дополнительных вопросов, оно пока не готово для качественного тест-дизайна.

Полезные определения терминов:

ISTQB Glossary — словарь терминов тестирования.

Типы проблем в требованиях, которые QA должен находить

Ниже — практическая классификация проблем, которую удобно использовать в промптах и в таблицах анализа.

| Тип проблемы | Как выглядит в тексте | Почему плохо для тестирования | Пример вопроса QA | |---|---|---|---| | Неоднозначность | «быстро», «удобно», «при необходимости», «может» | Нельзя определить ожидаемый результат | Что считается “быстро”: SLO/секунды/перцентили? | | Неполнота | Не описаны ошибки, ограничения, статусы | Невозможно покрыть негативные сценарии | Какие сообщения показываем при ошибке? | | Противоречие | Два пункта говорят разное про одно и то же | Тесты конфликтуют, дефекты спорные | Какой пункт приоритетнее? | | Неопределённые данные | Не задан формат, валюта, таймзона, округление | Ожидаемый результат невалиден | В какой таймзоне хранится дата? | | Скрытые зависимости | Требование зависит от ролей/прав/интеграций, но это не описано | Пропускаются критичные проверки доступа и интеграций | Какие роли могут выполнять действие? | | Непроверяемость | «Система должна обеспечивать безопасность» | Нельзя сформулировать критерии приемки | Какие именно меры: 2FA, lockout, rate limit? |

Мини-процесс анализа требований с ИИ

Ниже — повторяемый контур, который вы будете применять и в следующих модулях (до генерации тестов и импорта в Zephyr).

!Блок-схема показывает, как из сырого текста получить тестопригодные правила, вопросы, критерии приемки и риски

Входные данные, которые надо дать ИИ

Минимально достаточный набор:

цель фичи и платформа (веб/мобайл/кросс-платформа);

роли пользователей;

текст требований (или выдержка);

известные ограничения (например, «без SSO», «оплата только картой»);

определение источника правды: «не добавляй сущности, которых нет в тексте».

Выходные артефакты анализа

В этом уроке мы фиксируем 4 результата:

структурированный список бизнес-правил (в терминах QA);

список вопросов и допущений (отдельно);

критерии приемки (желательно в формализованном виде);

реестр рисков (что и почему может пойти не так).

Как писать промпт для анализа требований

Принцип: вынудить ИИ быть доказательным. Просите не «придумать», а извлечь и обосновать.

Шаблон промпта: извлечение правил и проблем

Шаблон промпта: критерии приемки в Given/When/Then

Критерии приемки удобно писать в стиле Gherkin (Given/When/Then), чтобы они были однозначными и проверяемыми.

Справка по синтаксису:

Gherkin Reference — спецификация ключевых слов.

Пример: плохие требования и как ИИ помогает довести их до тестопригодных

Ниже — пример для веб-фичи. Сначала — сырой текст (типичный уровень «как пишут в чате»), затем — результат анализа.

Сырой текст требований (плохой)

Фича: восстановление пароля (веб)

Пользователь может восстановить пароль по email.

Письмо должно приходить быстро.

Ссылка действует недолго.

Если пользователь много раз пытается — надо ограничить.

Пароль должен быть надёжным.

Проблема: требования звучат «правдоподобно», но почти не тестируются без уточнений.

Пример ответа ИИ: извлечение правил и проблем (ожидаемый формат)

| Элемент | Содержание | |---|---| | R1 | Восстановление пароля доступно по email. | | R2 | После запроса восстановления отправляется email с ссылкой. | | R3 | Ссылка имеет ограниченный срок действия. | | R4 | Должно быть ограничение на частые/многократные попытки восстановления. | | R5 | Новый пароль должен соответствовать требованиям надёжности. |

| Цитата | Тип проблемы | Вопрос | Влияние на тестирование | |---|---|---|---| | «Письмо должно приходить быстро» | Неоднозначность | Какой SLA доставки: секунды/минуты? Как измеряем: перцентиль, среднее? | Нельзя определить pass/fail и построить тесты на производительность/ожидание | | «Ссылка действует недолго» | Неоднозначность | Сколько минут/часов живёт ссылка? Можно ли использовать повторно? | Нельзя тестировать истечение срока и повторное использование | | «много раз пытается — надо ограничить» | Неполнота | Сколько попыток? Окно времени? Что именно ограничиваем: запросы, клики по ссылке, смену пароля? | Риск пропуска brute-force/спама, невозможно построить таблицу решений | | «Пароль должен быть надёжным» | Непроверяемость | Какие правила: длина, классы символов, запрет совпадения со старым, запрет частых паролей? | Невозможно применить граничные значения и классы эквивалентности |

Как QA должен отреагировать на ответ ИИ

Этот ответ полезен, если вы:

подтверждаете, что правила извлечены, а не придуманы;

берёте блок вопросов как основу для уточнения требований;

не переходите к генерации тест-кейсов, пока не уточнены параметры.

Пример: как исправлять ошибки ИИ при анализе требований

ИИ часто пытается «улучшить продукт», добавляя детали. Ваша задача — отрезать домыслы.

Типовая ошибка: добавлен несуществующий канал восстановления

Неверный фрагмент ответа ИИ: «Пользователь может восстановить пароль по SMS или email».

Почему ошибка: в исходном требовании было только email.

Как исправить:

Применить правило контроля: каждое утверждение должно иметь цитату-основание.

Вернуть ИИ на рельсы уточняющим промптом.

Ожидаемое поведение: SMS уйдёт в Допущения или будет удалён.

Превращаем требования в критерии приемки

Критерии приемки — это договорённость, по которой команда понимает: сделано ли требование.

Практический критерий качества: каждый AC должен быть проверяемым и содержать наблюдаемый результат.

Когда нужны критерии приемки

Критерии приемки особенно важны, когда:

есть состояние и переходы (создано/подтверждено/отменено);

есть ограничения и лимиты (кол-во попыток, TTL, диапазоны);

есть роли и права;

есть интеграции (почта, платёж, push).

Пример AC (после уточнения требований)

Ниже — пример того, как может выглядеть результат после того, как команда ответила на вопросы (цифры и лимиты здесь приведены как иллюстрация формата, а не как «истина из воздуха»).

Предположим, после уточнений требования стали такими:

R1: Восстановление доступно только по email.

R2: Письмо отправляется в течение 2 минут в 95% случаев.

R3: Ссылка действительна 30 минут и одноразовая.

R4: Не более 3 запросов восстановления за 10 минут на один email; при превышении показываем сообщение и не отправляем письмо.

R5: Новый пароль 10–64 символа, минимум 1 цифра и 1 спецсимвол.

AC1 (R1, R2)

Given пользователь находится на странице восстановления пароля

When он вводит зарегистрированный email и отправляет форму

Then система показывает сообщение «Письмо отправлено»

And письмо приходит на указанный адрес (для метрик SLA — замеряется временем доставки)

AC2 (R3)

Given пользователь получил письмо со ссылкой

When он открывает ссылку позже чем через 30 минут после отправки

Then система показывает сообщение об истечении срока действия ссылки

And смена пароля недоступна

AC3 (R4)

Given пользователь отправил 3 запроса восстановления для одного email за последние 10 минут

When он отправляет 4-й запрос

Then система показывает сообщение «Слишком много попыток. Повторите позже»

And письмо не отправляется

AC4 (R5)

Given пользователь открыл валидную ссылку восстановления

When он вводит новый пароль, не соответствующий правилам сложности

Then система показывает сообщение валидации и не сохраняет пароль

Трассируемость AC к правилам

| AC | Покрытые правила | |---|---| | AC1 | R1, R2 | | AC2 | R3 | | AC3 | R4 | | AC4 | R5 |

Эта трассируемость пригодится дальше: из неё вы будете генерировать тесты и связывать их с требованиями.

Риски: что именно искать QA и как просить ИИ

Риск в контексте QA — это вероятность дефекта, помноженная на ущерб. В рамках практики курса вам важно уметь:

перечислить риски по фиче;

связать каждый риск с причиной (требованием/неясностью/технологией);

определить направление тестирования.

Категории рисков (практическая матрица)

| Категория | Примеры для требований | Что проверять потом | |---|---|---| | Функциональные | неверная логика лимитов, неправильные статусы | переходы, таблицы решений, негативные сценарии | | Данные | таймзона, формат email, нормализация строк | граничные значения, локаль, кодировки | | Безопасность | перебор токена, утечка аккаунтов через сообщения | rate limit, одноразовость, одинаковые сообщения об ошибке | | UX/доступность | непонятные ошибки, недоступная форма | тексты ошибок, состояния загрузки, a11y-атрибуты | | Совместимость | разные браузеры, мобильные клиенты | кросс-браузер/кросс-девайс | | Интеграции | почта, push, сторонние сервисы | ретраи, таймауты, идемпотентность |

Шаблон промпта: реестр рисков

Пример реестра рисков (фрагмент)

| Risk ID | Описание | Причина | Последствие | Направление тестирования | |---|---|---|---|---| | RK1 | Пользователь может спамить запросами восстановления | Неясный лимит попыток (R4) | Нагрузка на почту, возможность DoS | таблица решений по лимитам, тесты на rate limit | | RK2 | Ссылка восстановления может быть повторно использована | Неясность «одноразовость» (R3) | Компрометация аккаунта | негативные сценарии на повторное открытие/использование | | RK3 | По сообщению об ошибке можно определить, зарегистрирован ли email | Нет требований к текстам ошибок | утечка информации о пользователях | тесты на одинаковые ответы/сообщения |

Практические кейсы анализа требований (веб, мобильный, кросс-платформа)

Здесь — три коротких кейса, чтобы закрепить, что именно нужно вытаскивать из текста, прежде чем делать тест-дизайн.

Веб-кейс: фильтры каталога

Фрагмент требований:

«Фильтр по цене должен работать быстро и обновлять список товаров без перезагрузки страницы».

Что извлекать и уточнять:

«быстро» — метрика и условие замера.

«без перезагрузки» — допускается ли изменение URL, история браузера.

поведение при пустой выдаче, при ошибке бекенда.

Мобильный кейс: push-уведомления

Фрагмент требований:

«Приложение отправляет push о статусе заказа, если пользователь разрешил уведомления».

Что уточнять:

какие статусы отправляют push, есть ли дедупликация.

что происходит при запрете уведомлений: показываем ли in-app баннер.

ограничения платформ: iOS/Android, фоновый режим.

Кросс-платформенный кейс: корзина на сайте и в приложении

Фрагмент требований:

«Корзина синхронизируется между сайтом и мобильным приложением».

Что обязательно достать в правила:

идентификатор пользователя: по аккаунту или по устройству.

конфликт-резолюция: что если добавили разные товары одновременно.

задержка синхронизации и допустимая несогласованность.

В следующих уроках вы возьмёте такие уточнённые правила и построите тест-дизайн (классы эквивалентности, границы, таблицы решений), а затем — тест-кейсы и CSV под импорт в Zephyr.

Чек-лист QA-валидации результата ИИ для анализа требований

Используйте этот список каждый раз, когда ИИ выдаёт «анализ».

Есть ли у каждого правила опора на текст (цитата/evidence).

Не добавлены ли новые сущности (экраны, поля, роли, интеграции).

Разделены ли Вопросы и Допущения (и не замаскированы ли допущения под факты).

Критерии приемки проверяемы: в Then есть наблюдаемый результат.

Риски привязаны к правилам/проблемам, а не «вообще про всё».

Выход структурирован так, чтобы его можно было использовать дальше (трассируемость R и AC).

Итоги урока

После этого урока ваш рабочий подход должен выглядеть так:

Сначала — извлечение бизнес-правил и проблем из текста, без домыслов.

Затем — вопросы и уточнения, которые делают требования тестопригодными.

После — критерии приемки в формализованном виде и минимальный реестр рисков.

И только потом — тест-дизайн и тест-кейсы (следующие уроки курса).

Тест-дизайн с ИИ: стратегии покрытий, чек-листы, тест-кейсы

Связь с предыдущими уроками

В прошлых статьях курса вы научились:

воспринимать ИИ как быстрого стажёра, а QA как владельца качества результата;

извлекать из требований тестопригодные бизнес-правила R, критерии приёмки AC, вопросы и риски.

Этот урок продолжает цепочку:

правила и AC превращаем в тестовые условия;

тестовые условия покрываем техниками тест-дизайна;

результат оформляем как чек-листы и тест-кейсы (с трассируемостью к R и AC).

!Схема показывает, как из правил и рисков получить тестовые артефакты с контролем качества

Что такое тест-дизайн и зачем он нужен до написания тест-кейсов

Тест-дизайн — это этап, на котором вы:

определяете что именно проверять (тестовые условия);

выбираете как покрыть условия минимальным, но достаточным набором тестов (техники);

фиксируете ожидаемые результаты так, чтобы они были проверяемыми.

Если пропустить тест-дизайн и сразу попросить ИИ: «сгенерируй тест-кейсы», вы почти гарантированно получите:

неполное покрытие (много позитивных, мало негативных и граничных);

домыслы (добавленные поля, статусы, интеграции);

шум (десятки однотипных кейсов без структуры).

Ориентир по терминологии тест-дизайна можно сверять в ISTQB Glossary.

Стратегия покрытия: как QA решает, сколько тестов достаточно

ИИ может предложить варианты, но стратегию покрытия задаёт QA. Практичная рамка для этого курса:

Покрытие требований

1. Каждый R и AC должен быть покрыт хотя бы одним тестом. 2. Трассируемость обязательна: тест без ссылки на R или AC считается подозрительным.

Покрытие рисков

1. Для каждого значимого риска из реестра должны быть тесты, которые реально способны его поймать. 2. Риск часто означает негативный сценарий или пограничное состояние.

Покрытие по техникам

1. Валидация полей и диапазонов: классы эквивалентности и граничные значения. 2. Комбинации условий: таблица решений. 3. Жизненный цикл объекта: переходы состояний. 4. Много параметров: попарное (pairwise) покрытие как компромисс.

Минимальный набор артефактов на выходе тест-дизайна

Чтобы работа была управляемой и пригодной для импорта в системы управления тестами, фиксируйте минимум:

Матрицу трассируемости R/AC -> Test IDs.

Тестовые условия (test conditions) с привязкой к правилам.

Выбранные техники для каждого условия.

Набор проверок в виде чек-листа и/или тест-кейсов.

Чек-лист и тест-кейс: что выбирать и как просить ИИ

Когда достаточно чек-листа

Чек-лист подходит, когда:

шаги очевидны и повторяются;

важнее полнота охвата, чем детальная воспроизводимость;

проверки исследовательские или быстро меняются.

Пример формата чек-листа (структурированного):

| ID | Проверка | Ожидаемый результат | Ссылка на правило | |---|---|---|---| | CL-01 | Ввести валидное значение и сохранить | Данные сохранены, отображаются после обновления | R1 | | CL-02 | Ввести невалидное значение | Показано конкретное сообщение об ошибке, сохранение недоступно | R2 |

Когда нужен тест-кейс

Тест-кейс нужен, когда:

есть критичная бизнес-логика или регресс;

важна воспроизводимость (любой QA должен повторить);

есть сложные предусловия, роли, состояния, интеграции.

Рекомендуемый минимальный шаблон тест-кейса:

| Поле | Правило качества | |---|---| | Название | Однозначно: действие + объект + условие | | Предусловия | Состояния, роль, данные, окружение | | Шаги | Нумерованные, без двусмысленностей | | Ожидаемый результат | Наблюдаемый: сообщение, статус, значение поля | | Теги/компоненты | Для фильтрации и отчётности | | Трассируемость | R и/или AC |

Техники тест-дизайна и как применять их с ИИ

Ниже — техники, которые чаще всего дают максимальный эффект в ручном тестировании и хорошо масштабируются с помощью ИИ.

Классы эквивалентности

Классы эквивалентности делят множество входных данных на группы, внутри которых система должна вести себя одинаково.

Используйте, когда:

есть валидация полей;

есть бизнес-правила по форматам и ограничениям.

Что просить у ИИ:

выделить валидные и невалидные классы;

для каждого класса предложить минимальные репрезентативные значения;

не придумывать форматы, которых нет в правилах.

Граничные значения

Граничные значения — проверки около границ диапазонов, где чаще всего возникают дефекты.

Используйте, когда:

есть диапазоны длины, суммы, количества, времени;

есть лимиты попыток и окна времени.

Что просить у ИИ:

дать значения на границе, внутри, снаружи;

учитывать включительность границ (например, <= 10 и < 10 дают разные наборы).

Таблица решений

Таблица решений нужна, когда результат зависит от комбинации условий.

Используйте, когда:

есть правила вида «если … и …, то …»;

есть лимиты, роли, флаги, разрешения.

Что просить у ИИ:

перечислить условия и действия;

построить минимальный набор правил (колонок);

явно указать, какие комбинации невозможны или не определены требованиями.

Переходы состояний

Переходы состояний применяйте, если объект меняет статусы (заказ, корзина, заявка).

Что просить у ИИ:

список состояний и переходов только из требований;

тесты на допустимые и недопустимые переходы;

проверки идемпотентности (повтор действия) там, где это критично.

Pairwise (попарное покрытие)

Pairwise — компромисс, когда параметров много, а полное комбинаторное покрытие дорого.

Что важно:

pairwise не заменяет критичные негативные кейсы и границы;

его применяют после того, как выделены классы и границы.

Промпты для ИИ: от правил к тестовому набору

Дальше — практические шаблоны промптов, которые вы сможете копировать.

Промпт: преобразовать R и AC в тестовые условия

Промпт: сгенерировать тестовые данные для классов и границ

Промпт: превратить тестовые условия в чек-лист и тест-кейсы

Пример: веб-кейс (фильтр каталога по цене)

Уточнённые правила и AC (вход для тест-дизайна)

Предположим, после анализа требований команда согласовала:

R1: Фильтр по цене принимает диапазон min и max в рублях, целые числа.

R2: min и max могут быть пустыми по отдельности, но не могут быть оба пустыми.

R3: Если min > max, показываем сообщение "Минимальная цена не может быть больше максимальной", фильтр не применяется.

R4: Диапазон допустимых значений 0–1 000 000.

R5: Применение фильтра обновляет список товаров без перезагрузки страницы.

Критерии приёмки:

AC1 (R1, R2, R4): При вводе валидных значений фильтр применяется.

AC2 (R3): При min > max показываем сообщение и не меняем выдачу.

AC3 (R5): При применении фильтра нет полной перезагрузки страницы.

Тестовые условия (пример результата)

| ID | Тестовое условие | Покрытие | Техника | |---|---|---|---| | TCND-01 | Применение фильтра при валидных диапазонах | R1, R4, AC1 | классы эквивалентности + границы | | TCND-02 | Применение фильтра при пустом min или пустом max | R2, AC1 | классы эквивалентности | | TCND-03 | Ошибка при min > max, выдача не меняется | R3, AC2 | границы + негативный сценарий | | TCND-04 | Значения вне 0–1 000 000 отклоняются | R4, AC1 | граничные значения | | TCND-05 | Нет полной перезагрузки страницы при применении фильтра | R5, AC3 | проверка UX/технического эффекта |

Чек-лист smoke (пример)

| ID | Проверка | Ожидаемый результат | Ссылка | |---|---|---|---| | CL-WEB-01 | Указать min=0, max=1000, применить | Выдача обновилась, отображаются товары в диапазоне | R1, R4 | | CL-WEB-02 | Оставить min пустым, max=500, применить | Выдача обновилась по верхней границе | R2 | | CL-WEB-03 | Указать min=1000, max=0, применить | Сообщение об ошибке, выдача не изменена | R3 | | CL-WEB-04 | Применить фильтр и убедиться, что нет полной перезагрузки | Нет полной перезагрузки страницы | R5 |

Тест-кейсы (пример)

| ID | Название | Предусловия | Шаги | Ожидаемый результат | Трассируемость | |---|---|---|---|---|---| | TC-WEB-01 | Фильтр по цене применяет диапазон 0–1000 | Открыт каталог товаров | 1. Ввести min=0 2. Ввести max=1000 3. Нажать Применить | 1. Выдача обновилась 2. Товары вне диапазона не отображаются | R1, R4, AC1 | | TC-WEB-02 | Ошибка при min > max и выдача не меняется | Открыт каталог, запомнить первые 3 товара из выдачи | 1. Ввести min=1000 2. Ввести max=0 3. Нажать Применить | 1. Показано сообщение "Минимальная цена не может быть больше максимальной" 2. Первые 3 товара в выдаче не изменились | R3, AC2 | | TC-WEB-03 | Валидация значения ниже 0 | Открыт каталог | 1. Ввести min=-1 2. Ввести max=100 3. Нажать Применить | 1. Фильтр не применяется 2. Показано сообщение о недопустимом значении или подсветка поля (как определено UI) | R4, AC1 |

Пример: мобильный кейс (push-уведомления о статусе заказа)

Уточнённые правила (пример)

R1: Push отправляется при смене статуса заказа на "Передан в доставку" и "Доставлен".

R2: Push отправляется только если:

- пользователь авторизован; - в настройках приложения включены уведомления; - на уровне ОС разрешены уведомления.

R3: Если push недоступен по любой причине из R2, приложение показывает in-app уведомление в центре уведомлений приложения.

Таблица решений для R2–R3 (пример)

| Условие | Обозначение | |---|---| | Пользователь авторизован | A | | Уведомления включены в приложении | B | | Уведомления разрешены в ОС | C |

| Правило | A | B | C | Ожидаемое действие | |---|---|---|---|---| | DR-01 | Да | Да | Да | Отправить push | | DR-02 | Нет | | | Не отправлять push, показать in-app | | DR-03 | Да | Нет | * | Не отправлять push, показать in-app | | DR-04 | Да | Да | Нет | Не отправлять push, показать in-app |

* означает, что значение условия не влияет на решение, потому что исход уже определён.

Тест-кейсы по таблице решений (фрагмент)

| ID | Название | Предусловия | Шаги | Ожидаемый результат | Трассируемость | |---|---|---|---|---|---| | TC-MOB-01 | Push приходит при статусе Передан в доставку при выполнении условий | Пользователь авторизован; уведомления включены в приложении; уведомления разрешены в ОС; есть заказ | 1. Сменить статус заказа на Передан в доставку (через тестовую среду/эмуляцию) 2. Дождаться события | Push получен, текст соответствует статусу | R1, R2, DR-01 | | TC-MOB-02 | In-app показывается, если уведомления ОС запрещены | Пользователь авторизован; уведомления включены в приложении; уведомления ОС запрещены | 1. Сменить статус заказа на Доставлен 2. Открыть центр уведомлений приложения | Push не получен; в центре уведомлений есть запись о статусе | R1, R2, R3, DR-04 |

Пример: кросс-платформенный кейс (синхронизация корзины веб + мобайл)

Уточнённые правила (пример)

R1: Корзина синхронизируется по аккаунту пользователя.

R2: При добавлении товара на одном устройстве корзина на другом обновляется в течение 10 секунд.

R3: Если один и тот же товар добавлен с двух устройств, итоговое количество равно сумме добавлений.

R4: Если товар удалён на одном устройстве, он удаляется и на другом.

Тестовые условия (фрагмент)

| ID | Условие | Покрытие | Техника | |---|---|---|---| | TCND-X-01 | Синхронизация добавления товара между платформами в пределах 10 секунд | R1, R2 | переходы состояния + тайминг | | TCND-X-02 | Конфликт добавления одного товара с двух устройств | R3 | комбинации условий | | TCND-X-03 | Синхронизация удаления товара | R4 | переходы состояния |

Тест-кейс на конфликт (пример)

| ID | Название | Предусловия | Шаги | Ожидаемый результат | Трассируемость | |---|---|---|---|---|---| | TC-X-01 | Суммирование количества при одновременном добавлении на веб и мобайле | Пользователь вошёл в один аккаунт на веб и мобайле; корзина пуста; выбран товар SKU-1 | 1. На веб добавить SKU-1 в количестве 1 2. В течение 3 секунд на мобайле добавить SKU-1 в количестве 2 3. Открыть корзину на обоих клиентах | На веб и мобайле количество SKU-1 равно 3; расхождений нет после синхронизации (до 10 секунд) | R1, R2, R3 |

Типовые ошибки ИИ в тест-дизайне и как их исправлять

Ошибка: ИИ генерирует тесты без опоры на правила

Признаки:

в тестах появляются поля, которых нет в требованиях;

expected result общими словами;

нет ссылок на R и AC.

Корректирующий промпт:

Ошибка: ИИ даёт слишком много тестов без структуры

Исправление: требовать тестовые условия и техники до тест-кейсов.

Корректирующий промпт:

Ошибка: слабые ожидаемые результаты

Исправление: требовать наблюдаемость.

Корректирующий промпт:

Контроль качества тестового набора, сгенерированного ИИ

Используйте этот чек-лист ревью перед тем, как переносить артефакты в систему управления тестами.

Трассируемость:

- каждый тест связан с R и/или AC; - нет тестов, которые нельзя обосновать источником.

Полнота:

- для каждого правила с диапазонами есть границы; - для комбинаций условий есть таблица решений или эквивалент; - негативные сценарии присутствуют, а не добавлены «для галочки».

Проверяемость:

- expected result наблюдаемый и однозначный; - нет скрытых допущений.

Консистентность:

- единые термины и статусы; - одинаковые ожидаемые результаты для одинаковых условий.

Практичность:

- тесты сгруппированы (по фичам/правилам/рискам); - выделен smoke-набор (чек-лист или теги).

Итоги урока

После этого урока ваш рабочий конвейер должен выглядеть так:

вы берёте R, AC, риски и превращаете их в тестовые условия;

выбираете технику тест-дизайна под каждое условие;

просите ИИ сгенерировать сначала структуру (условия, таблицы, классы/границы), а затем артефакты (чек-лист, тест-кейсы);

валидируете результат по трассируемости, проверяемости и полноте.

Следующий шаг курса — подготовить тест-кейсы к промышленному хранению: структура Jira/Zephyr и генерация CSV для импорта, чтобы перенос из результатов ИИ в Zephyr был быстрым и без ручного форматирования.

Промпт-инжиниринг для QA: шаблоны, контекст, валидация

Связь с предыдущими статьями курса

В прошлых статьях курса вы закрепили два ключевых принципа:

ИИ — стажёр, который ускоряет черновики артефактов, но не отвечает за доменную корректность и достаточность покрытия.

Перед тест-дизайном QA превращает «сырой текст» в тестопригодные артефакты: бизнес-правила R, критерии приёмки AC, вопросы, риски.

Эта статья отвечает на практический вопрос: как писать промпты так, чтобы результат был управляемым, проверяемым и пригодным для дальнейшего переноса в тест-менеджмент (включая Zephyr).

!Контур работы QA с ИИ: от входных данных к проверенному артефакту

Что такое промпт-инжиниринг в QA

Промпт-инжиниринг в рамках курса — это дисциплина постановки задачи ИИ так, чтобы:

ИИ работал в рамках источника правды (требований/правил), не додумывая продукт;

результат был структурирован и валидируем QA по чек-листу;

артефакт был трассируем (тесты привязаны к R/AC), а не набором «идей».

Здесь важна инженерная, а не литературная постановка: вы формируете контракт на вход и выход.

Термины, которые используются в статье

Контекст — вся информация, задающая рамки: платформа, роль пользователя, функциональность, ограничения.

Источник правды — то, что считается приоритетным и единственным основанием для выводов (например, список R и AC).

Трассируемость — связь теста/проверки с конкретным правилом или критерием приёмки.

Валидация результата ИИ — проверка ответа по критериям качества: доказуемость, полнота, проверяемость, формат.

Если нужно свериться с базовой терминологией тестирования, используйте ISTQB Glossary.

Почему у QA-подхода к промптам есть специфика

Если вы попросите: Сгенерируй тест-кейсы для фичи, то почти неизбежно получите:

домыслы (добавленные поля, статусы, интеграции);

слабые expected results (неизмеримые формулировки);

отсутствие структуры (нет техники тест-дизайна и покрытия рисков);

проблемы импорта в инструменты (форматы не совпадают).

QA-подход требует, чтобы ответ:

был обоснован источником;

был тестопригоден (можно однозначно проверить pass/fail);

был ограничен техникой тест-дизайна;

был пригоден для хранения (шаблоны и поля).

Промпт-контракт: минимальная структура, которая даёт контроль

Ниже — шаблон, который можно считать «скелетом» почти любого промпта в этом курсе.

Ключевой эффект: вы превращаете «творческую генерацию» в воспроизводимую процедуру.

Блоки контекста: что QA обязан фиксировать явно

ИИ чаще всего ошибается не потому, что «плохой», а потому что контекст не определён. Минимум, который стоит фиксировать в каждом промпте:

Платформа и канал

- веб / iOS / Android / API / кросс-платформа

Акторы и роли

- пользователь, админ, гость, курьер, оператор

Границы фичи

- что входит и что не входит (например, «без SSO», «без SMS», «без интеграции X»)

Точки наблюдения

- где подтверждать результат: UI-сообщение, статус, запись в истории, изменение данных

Ограничения по данным

- нельзя использовать реальные персональные данные; только синтетические

Рекомендации по управлению рисками ИИ и безопасностью полезно держать как фон: NIST AI Risk Management Framework и OWASP Top 10 for LLM Applications.

Инструменты контроля: как «запереть» ИИ в источнике правды

Чтобы снизить галлюцинации, в QA-промптах используются жёсткие ограничители.

Требование к доказательности

Просите добавлять к каждому пункту поле Evidence.

Для анализа требований Evidence обычно является цитатой из исходного текста.

Для тестов Evidence — ссылка на R/AC, которые обосновывают проверку.

Пример формулировки:

Разделение «Факты / Вопросы / Допущения»

ИИ склонен превращать допущения в утверждения. Разделение принуждает его маркировать неопределённости.

Факты — только то, что следует из источника.

Вопросы — что надо уточнить у BA/PO/разработки.

Допущения — временные гипотезы для продолжения работы, но не требования.

Трассируемость как обязательное поле

В тестовых артефактах требуйте колонку Trace.

Trace должен содержать R и/или AC.

Любой тест без Trace считается кандидатом на удаление или перенос в «идеи».

Формат как способ управления качеством

Формат вывода — это не «косметика», а средство проверки.

Правило

Чем строже формат, тем проще:

проверить консистентность;

найти пропуски;

перенести артефакт в инструменты.

Примеры полезных форматов

Таблица для анализа требований

- ID, Rule, Evidence, Issue type, Question, Impact

Таблица для тестовых условий

- TCND-ID, Condition, Technique, Trace, Notes

Таблица для тест-кейсов

- ID, Title, Preconditions, Steps, Expected, Trace, Tags

Библиотека промптов QA: шаблоны для типовых задач

Ниже — шаблоны, которые согласуются с предыдущими уроками: сначала R/AC, затем тест-дизайн.

Извлечь правила из требований и найти проблемы

Превратить правила в критерии приёмки Given/When/Then

Синтаксис Given/When/Then описан в Gherkin Reference.

Построить тестовые условия и выбрать технику тест-дизайна

Превратить тестовые условия в чек-лист и тест-кейсы

Подготовить выход под импорт в Zephyr

Это курс про генерацию импорта, поэтому важен принцип: формат фиксируем заранее. Официальные детали форматов и полей зависят от редакции Zephyr, сверяйте по документации вашей версии: Zephyr Scale Cloud Documentation.

Универсальная техника промпта:

вы даёте ИИ пример CSV с заголовками, который импортируется у вас;

просите сгенерировать новые строки строго в этом формате;

запрещаете менять заголовки и добавлять колонки.

Пример: как один и тот же запрос превращается в управляемый промпт

Плохой промпт

Сгенерируй тест-кейсы для фильтра по цене.

Почему он неконтролируемый:

нет источника правды;

не задана платформа и формат полей;

не задана техника тест-дизайна;

нет требований к трассируемости и expected result.

Хороший промпт (управляемый)

Проверяемость результата здесь обеспечивается тем, что:

есть явные R*;

есть указание техник;

есть формат и требование Trace.

Валидация ответа ИИ: чек-лист QA-ревью

Этот чек-лист применяйте к любому артефакту от ИИ: правила, AC, тестовые условия, тест-кейсы, CSV.

Источник правды и домыслы

- каждый пункт имеет Evidence или Trace - нет добавленных полей/статусов/экранов, которых нет в источнике

Проверяемость expected result

- expected result наблюдаем и однозначен - нет формулировок «успешно/корректно/работает» без критерия

Полнота по техникам

- для диапазонов есть границы и «около границы» - для комбинаций условий есть таблица решений или эквивалент - негативные сценарии не забыты

Консистентность

- единые термины, статусы, форматы данных - одинаковые условия дают одинаковый ожидаемый результат

Формат и переносимость

- таблицы содержат обязательные колонки - при подготовке CSV заголовки и разделители не нарушены

Как исправлять типовые ошибки ИИ с помощью корректирующих промптов

Здесь важен принцип: не ругаться с ответом, а менять контракт.

Ошибка: добавлены несуществующие сущности

Корректирующий промпт:

Ошибка: слишком много тестов без структуры

Корректирующий промпт:

Ошибка: слабые expected results

Корректирующий промпт:

Ошибка: смешаны «вопросы» и «допущения»

Корректирующий промпт:

Практический принцип для следующих модулей: готовность к Zephyr начинается в промпте

Хотя детальная генерация импорта в Zephyr будет отдельным этапом курса, важно заранее привыкнуть к двум привычкам:

каждый тест-кейс должен иметь стабильные поля (название, предусловия, шаги, expected result, trace, теги)

формат должен быть машиночитаемым и предсказуемым, иначе импорт станет ручной чисткой

Если вы уже на этапе промпта фиксируете формат таблицы и дисциплину Trace, то переход к CSV и импорту по документации Zephyr будет почти механическим.

Итоги

После этой статьи у вас должен быть воспроизводимый подход:

вы задаёте промпт-контракт (контекст, источник правды, ограничения, формат, критерии качества)

вы принуждаете ИИ к доказательности через Evidence/Trace

вы валидируете результат чек-листом QA (трассируемость, проверяемость, полнота по техникам, формат)

вы исправляете ошибки не «ручной правкой текста», а корректирующим промптом, меняя входные ограничения

Следующие шаги курса используют этот фундамент: генерация тестовых артефактов в формате, который безболезненно переносится в Jira/Zephyr и импортируется без разрушения структуры.

Zephyr и Jira: структура, поля, подготовка CSV для импорта

Связь с предыдущими статьями курса

В предыдущих статьях вы построили управляемый конвейер:

из «сырого текста» требований извлекаете бизнес-правила R\ и критерии приемки AC\;

превращаете их в тестовые условия и тест-кейсы с трассируемостью;

фиксируете формат ответа ИИ так, чтобы его можно было валидировать.

Эта статья закрывает практический разрыв между «таблицей тест-кейсов» и промышленным хранением в инструментах:

как обычно организованы артефакты в Jira и Zephyr;

какие поля критичны для качества (и импорта);

как подготовить CSV так, чтобы импорт прошёл без ручной чистки;

как использовать ИИ строго как генератор строк по шаблону, а не как источник истины.

!Конвейер от требований до импортированных тест-кейсов и выполнения в Zephyr

Базовая модель: что хранится в Jira, а что в Zephyr

Jira как система управления разработкой

В Jira обычно живут:

Epic и Story или Task как носители требований.

Bug как дефекты.

Компоненты, версии, приоритеты, исполнители и статусы workflow.

Документация:

Jira Cloud documentation

Zephyr как система управления тестированием

В Zephyr (в частности, Zephyr Scale для Jira) обычно живут:

Test Case как сущность «как проверять».

Test Cycle как сущность «когда и в каком наборе выполняем».

Test Execution как сущность «факт выполнения конкретного теста с результатом».

Документация:

Zephyr Scale Cloud documentation

Практическое правило трассируемости

Чтобы результат ИИ был управляемым, а тест-репозиторий не превращался в свалку:

Требования хранятся в Jira (Story/Task) и имеют ключ, например WEB-123.

Тест-кейсы хранятся в Zephyr и обязаны иметь ссылку на источник:

1. ссылку на Jira-issue (requirement/story), или 2. ссылку на R\/AC\ внутри описания, если команда пока ведёт правила вне Jira.

Идеально: в тест-кейсе есть и ссылка на Jira-issue, и перечисление покрываемых R\/AC\.

Минимальная структура проекта: чтобы импорт и поиск работали

Ниже — структура, которая масштабируется и под веб, и под мобайл, и под кросс-платформу.

Соглашения по именованию

Jira project key: короткий, стабильный, например WEB, MOB, XPL.

Компоненты Jira: соответствуют подсистемам, например Catalog, Auth, Notifications.

Labels (теги) в тестах: для фильтрации набора, например smoke, regression, negative, bva.

Папки (folders) в Zephyr: отражают функциональные области и платформу.

Пример структуры папок Zephyr

| Платформа | Папка верхнего уровня | Примеры подпапок | |---|---|---| | Веб | WEB | WEB/Auth, WEB/Catalog, WEB/Checkout | | Мобайл | MOB | MOB/Orders, MOB/Notifications, MOB/Settings | | Кросс-платформа | XPL | XPL/Cart Sync, XPL/Profile Sync |

Пример структуры в Jira для трассируемости

| Что нужно связать | Где хранить | Как обозначать | |---|---|---| | Требование | Jira Story/Task | WEB-123 | | Тест-кейс | Zephyr Test Case | TEST-456 (генерируется Zephyr) | | Связь | Link между issue | Link type вроде tests/is tested by зависит от настроек |

Важно: конкретные типы связей в Jira зависят от конфигурации. В рамках курса достаточно договориться, что тест-кейс всегда содержит ключ Jira-issue в отдельном поле или в начале описания.

Поля тест-кейса: что реально влияет на качество и импорт

Независимо от конкретного набора полей в вашей инсталляции Zephyr, у тест-кейса должны быть элементы, которые вы уже требовали от ИИ в прошлых уроках.

Минимально достаточные поля тест-кейса

| Поле | Зачем нужно QA | Типовая ошибка ИИ | |---|---|---| | Name или Title | Поиск, отчётность, читаемость | слишком общее название без условия | | Objective или Description | Контекст проверки и бизнес-смысл | пересказ без критериев | | Precondition | Воспроизводимость | скрытые допущения | | Test script (шаги и expected) | Проверяемость | expected без наблюдаемых критериев | | Labels / Tags | Быстрые выборки (smoke, regression) | отсутствие тегов, смешение смыслов | | Folder | Стабильная навигация | импорт в корень без структуры | | Priority | Приоритизация регресса | выставлено «на глаз», без договорённости | | Trace (Jira key, R\/AC\) | Доказуемость и покрытие требований | тесты «в вакууме» |

Наблюдаемость expected result

Expected result считается качественным, если он проверяемый:

конкретный текст сообщения;

конкретное изменение статуса;

появление или исчезновение элемента UI;

конкретное значение в поле;

факт отсутствия действия, если оно запрещено.

Формулировки вроде «успешно», «корректно», «работает» без наблюдаемого критерия — дефект тест-кейса.

CSV для импорта: ключевой принцип и почему он важнее «идеального формата»

Формат CSV для импорта зависит от:

версии Zephyr;

выбранного варианта импорта;

включённых полей;

настроек разделителей и поддерживаемого типа скрипта.

Поэтому главный принцип курса:

В вашей инсталляции создайте один тест-кейс вручную.

Экспортируйте его в CSV.

Используйте заголовки и порядок столбцов из экспорта как единственный источник истины.

Просите ИИ генерировать только строки данных строго под этот шаблон.

Документация по возможностям импорта и CSV:

Zephyr Scale Cloud documentation

Практические правила CSV: чтобы импорт не ломался

Ниже — правила, которые чаще всего предотвращают ошибки импорта.

Кодировка и разделители

Сохраняйте CSV в UTF-8.

Используйте один разделитель на весь файл.

Если ваши данные содержат запятые, безопаснее:

1. использовать кавычки вокруг каждого поля, или 2. перейти на разделитель ;, если это поддерживается импортом в вашей конфигурации.

Кавычки и переносы строк внутри ячеек

Если значение содержит запятые или переносы строк, поле должно быть в двойных кавычках.

Если внутри текста нужны двойные кавычки, они экранируются удвоением: "".

Переносы строк в шагах допустимы только если импорт вашей версии Zephyr это поддерживает, иначе используйте явные разделители шагов в одной строке.

Пустые значения

Если поле необязательное и вы не знаете значение:

оставляйте пустую ячейку;

не придумывайте владельца, компонент или приоритет.

Эталонный CSV-шаблон для обучения и как адаптировать под вашу инсталляцию

Ниже — учебный шаблон, который отражает типовую структуру.

Важно: перед реальным импортом замените заголовки на те, что вы получили из экспорта вашей Zephyr-инсталляции.

Где в этом шаблоне должна быть трассируемость

Если ваша конфигурация импорта поддерживает отдельное поле для ссылки на requirement или Jira key, используйте его.

Если отдельного поля нет, используйте дисциплину в тексте:

В Objective или начале TestScript добавляйте строку Trace: WEB-123; R1; AC2.

Следите, чтобы Trace всегда ссылался на реальный Jira-issue или на ваши R\/AC\.

Как подготовить данные для импорта из результатов ИИ

Здесь важна последовательность: вы не «просите CSV», пока у вас не валидированы тест-кейсы.

Шаги процесса

У вас есть правила R\ и критерии AC\.

Вы сделали тест-дизайн и получили таблицу тест-кейсов с полями:

1. Title 2. Preconditions 3. Steps 4. Expected 5. Trace (R\/AC\ и Jira key) 6. Tags

Вы берёте CSV-шаблон из экспорта Zephyr.

Просите ИИ сгенерировать строки CSV, не меняя заголовки и порядок.

Делаете QA-валидацию CSV.

Импортируете и проверяете 2-3 теста вручную в интерфейсе.

Промпты для ИИ: генерация строк CSV без разрушения формата

Промпт-контракт для CSV

Корректирующий промпт, если ИИ ломает CSV

Валидация перед импортом: чек-лист QA

Проверяйте CSV как тестовый артефакт, а не как «текстовый файл».

Структура CSV:

1. заголовки полностью совпадают с экспортированным шаблоном; 2. одинаковое число столбцов в каждой строке; 3. нет лишних запятых из-за неэкранированного текста.

Содержимое тестов:

1. Name/Title однозначный и не дублируется; 2. Precondition описывает состояние, а не шаги; 3. Expected наблюдаемый.

Трассируемость:

1. в каждом тесте есть Trace на Jira key или на R\/AC\; 2. нет тестов без источника.

Классы и границы:

1. если тест про диапазон, присутствуют граничные значения; 2. если тест про комбинации условий, набор покрывает ключевые правила таблицы решений.

Организация:

1. Folder соответствует принятой структуре; 2. Labels позволяют собрать smoke и regression наборы.

Типовые проблемы импорта и как их диагностировать

| Симптом | Вероятная причина | Что сделать | |---|---|---| | Импорт падает сразу | заголовки не совпадают с шаблоном | заменить заголовки на экспортированные | | Часть строк импортировалась, часть нет | разное число столбцов в строках | проверить кавычки и запятые внутри текста | | Шаги «склеились» в один абзац | переносы строк не поддержаны в ячейке | заменить переносы на \n или формат шагов, который поддерживает ваша версия | | Появились «лишние» пустые тесты | пустые обязательные поля | определить обязательные поля по импорту и заполнить минимально | | Тесты в неправильной папке | неверное имя папки или несуществующий путь | привести Folder к существующей структуре |

Итог

После этой статьи ваш процесс должен быть устойчивым:

Zephyr хранит тест-кейсы, циклы и исполнения; Jira хранит требования и дефекты.

Качество тест-кейса определяется не красотой текста, а воспроизводимостью, наблюдаемым expected result и трассируемостью.

CSV для импорта нельзя «угадать»: правильный шаблон берётся из экспорта вашей инсталляции.

ИИ используется для перепаковки валидированных тест-кейсов в строки CSV по строгому контракту, а QA валидирует формат и содержимое перед импортом.

Практикумы: веб-кейс и мобильный кейс с полными артефактами

Связь с предыдущими статьями курса

В прошлых статьях вы построили конвейер работы с ИИ:

Анализ требований: извлечение тестопригодных правил R, критериев приемки AC, вопросов и рисков.

Тест-дизайн: преобразование R и AC в тестовые условия и покрытия техниками (EP/BVA/Decision Table/State Transition).

Промпт-инжиниринг: фиксация контекста, источника правды и формата, а также валидация ответа.

Zephyr/Jira: перенос тестов в промышленное хранение и генерация CSV строго по экспортированному шаблону.

Эта статья закрепляет весь конвейер на двух практикумах с полными артефактами:

Веб-кейс: фильтр каталога по цене.

Мобильный кейс: push-уведомления о статусе заказа.

!Конвейер от требований до импорта в Zephyr

Общие правила выполнения практикумов

Дисциплина источника правды

В каждом практикуме действуют одинаковые правила:

ИИ не имеет права добавлять сущности (экраны, поля, статусы, интеграции), которых нет в исходном тексте.

Все утверждения должны иметь обоснование:

1. На этапе анализа требований это Evidence (цитата из требований). 2. На этапе тестов это Trace (ссылки на R, AC, при наличии на ключ Jira).

Если данных не хватает, это не заполняется «правдоподобным текстом», а фиксируется как Вопросы.

Полезные справочники

Термины тестирования: ISTQB Glossary

Синтаксис Given/When/Then: Gherkin Reference

Документация по Zephyr Scale Cloud: Zephyr Scale Cloud documentation

Практикум: веб-кейс

Контекст

Фича: фильтр по цене в каталоге товаров веб-приложения.

Вход: плохие требования

Это типичный «сырой» текст, который нельзя тестировать без уточнений.

Пользователь может отфильтровать товары по цене.

Фильтр должен работать быстро.

Если пользователь ошибся, надо показать ошибку.

Всё должно обновляться без перезагрузки.

Вход: уточнённые требования для практикума

Чтобы практикум был проверяемым, ниже зафиксирован учебный набор правил.

Цена задаётся в рублях, целое число.

Два поля: min и max.

min и max могут быть пустыми по отдельности, но не могут быть оба пустыми.

Допустимый диапазон значений: от 0 до 1 000 000 включительно.

Если min > max, показываем сообщение "Минимальная цена не может быть больше максимальной", фильтр не применяется.

При применении фильтра список товаров обновляется без полной перезагрузки страницы.

Промпт для ИИ: извлечение правил и проблем

Пример ожидаемого результата: правила R* с Evidence

| Rule ID | Правило | Evidence | |---|---|---| | R1 | Цена задаётся в рублях, целое число | «Цена задаётся в рублях, целое число.» | | R2 | В фильтре есть поля min и max | «Два поля: min и max.» | | R3 | min и max могут быть пустыми по отдельности, но не могут быть оба пустыми | «могут быть пустыми по отдельности, но не могут быть оба пустыми.» | | R4 | Допустимый диапазон значений 0..1 000 000 включительно | «от 0 до 1 000 000 включительно.» | | R5 | При min > max показываем фиксированное сообщение и фильтр не применяется | «Если min > max, показываем сообщение ... фильтр не применяется.» | | R6 | При применении фильтра список обновляется без полной перезагрузки страницы | «обновляется без полной перезагрузки страницы.» |

Пример ожидаемого результата: проблемы требований, если использовать плохую версию

| Цитата | Тип проблемы | Вопрос | Влияние на тестирование | |---|---|---|---| | «работать быстро» | Неоднозначность | Как измеряем быстро: метрика (мс/сек), перцентиль, условия сети? | Нельзя определить pass/fail по производительности и UX | | «показать ошибку» | Неполнота | Какой текст ошибки для каждого вида невалидного ввода? Где показываем: под полем или общая? | Невозможно написать проверяемый expected result |

Критерии приемки AC* (Given/When/Then)

Ниже пример тестопригодного результата по уточнённым правилам.

| AC ID | Given | When | Then | Trace | |---|---|---|---|---| | AC1 | Открыт каталог, фильтр по цене доступен | Пользователь вводит min=0, max=1000 и применяет фильтр | Отображаются товары с ценой в диапазоне 0..1000; ошибок нет | R1,R2,R4 | | AC2 | Открыт каталог, фильтр по цене доступен | Пользователь оставляет min пустым, вводит max=500 и применяет фильтр | Отображаются товары с ценой <=500; ошибок нет | R2,R3,R4 | | AC3 | Открыт каталог, фильтр по цене доступен | Пользователь вводит min=1000, max=0 и применяет фильтр | Показано сообщение "Минимальная цена не может быть больше максимальной"; выдача не изменилась | R5 | | AC4 | Открыт каталог, фильтр по цене доступен | Пользователь применяет фильтр с валидными значениями | Обновление выдачи происходит без полной перезагрузки страницы | R6 |

Реестр рисков

| Risk ID | Риск | Причина | Последствие | Направление тестирования | |---|---|---|---|---| | RK-WEB-01 | Неверная обработка пустых значений min/max | R3 | Пользователь не сможет фильтровать по одной границе | EP по пустым/заполненным полям, негативные сценарии | | RK-WEB-02 | Ошибка min > max применяется как фильтр вместо блокировки | R5 | Пользователь получает пустую выдачу без объяснения | Негативный сценарий, проверка "не применяется" | | RK-WEB-03 | Валидация границ диапазона реализована неверно | R4 | Дефекты на 0, 1 000 000, значения за границей | BVA на границах и около границ | | RK-WEB-04 | Реализована полная перезагрузка страницы | R6 | Потеря состояния, ухудшение UX, проблемы SPA | Технический/UX чек: отсутствие полной навигации |

Тест-дизайн: тестовые условия TCND*

| TCND ID | Тестовое условие | Техника | Trace | |---|---|---|---| | TCND-WEB-01 | Применение фильтра при валидном диапазоне внутри границ | EP + BVA | R1,R2,R4,AC1 | | TCND-WEB-02 | Применение фильтра при пустом min или пустом max | EP | R2,R3,AC2 | | TCND-WEB-03 | Ошибка при min > max, фильтр не применяется | Негативный сценарий + BVA | R5,AC3 | | TCND-WEB-04 | Отклонение значений ниже 0 и выше 1 000 000 | BVA | R4 | | TCND-WEB-05 | Обновление выдачи без полной перезагрузки страницы | Проверка технического эффекта | R6,AC4 |

Чек-лист smoke

| ID | Проверка | Ожидаемый результат | Trace | |---|---|---|---| | CL-WEB-01 | min=0, max=1000, применить фильтр | Выдача обновилась; ошибки нет | AC1 | | CL-WEB-02 | min пусто, max=500, применить фильтр | Выдача обновилась; ошибки нет | AC2 | | CL-WEB-03 | min=1000, max=0, применить фильтр | Показано сообщение "Минимальная цена не может быть больше максимальной"; выдача не изменилась | AC3 | | CL-WEB-04 | Применить валидный фильтр и убедиться, что нет полной перезагрузки | Нет полной перезагрузки страницы | AC4 |

Набор тест-кейсов для регресса

Чтобы expected result был наблюдаемым, фиксируем точки наблюдения:

Сообщение об ошибке.

Изменение выдачи (и проверка "не изменилась" через сравнение элементов до/после).

Отсутствие полной перезагрузки (например, отсутствует полная навигация, не сбрасывается состояние SPA).

| ID | Название | Предусловия | Шаги | Ожидаемый результат | Trace | Теги | |---|---|---|---|---|---|---| | TC-WEB-01 | Применение диапазона 0..1000 | Открыт каталог | 1. Ввести min=0 2. Ввести max=1000 3. Нажать применить | 1. Отображаются товары с ценой 0..1000 2. Сообщений об ошибке нет | AC1 | regression;bva | | TC-WEB-02 | Применение фильтра только по max | Открыт каталог | 1. Оставить min пустым 2. Ввести max=500 3. Нажать применить | 1. Отображаются товары с ценой <=500 2. Сообщений об ошибке нет | AC2 | regression | | TC-WEB-03 | Ошибка при min > max, выдача не меняется | Открыт каталог; запомнить первые 3 товара в выдаче | 1. Ввести min=1000 2. Ввести max=0 3. Нажать применить | 1. Показано сообщение "Минимальная цена не может быть больше максимальной" 2. Первые 3 товара совпадают с запомненными | AC3 | regression;negative | | TC-WEB-04 | Граница: min=-1 отклоняется | Открыт каталог | 1. Ввести min=-1 2. Ввести max=100 3. Нажать применить | Фильтр не применяется или поле подсвечено как невалидное; отсутствует изменение выдачи, если UI блокирует применение | R4 | regression;bva;negative | | TC-WEB-05 | Граница: max=1000001 отклоняется | Открыт каталог | 1. Ввести min=0 2. Ввести max=1000001 3. Нажать применить | Фильтр не применяется или поле подсвечено как невалидное; отсутствует изменение выдачи, если UI блокирует применение | R4 | regression;bva;negative | | TC-WEB-06 | Нет полной перезагрузки при применении валидного фильтра | Открыт каталог | 1. Ввести min=10 2. Ввести max=20 3. Нажать применить | Обновление выдачи прошло без полной перезагрузки страницы | AC4 | smoke;regression |

Пример ошибки ИИ и корректировка промптом

Типовая ошибка: ИИ добавил правило про валюту USD и дробные значения.

Неверный фрагмент ответа ИИ:

Почему это ошибка: в источнике правды указано рубли и целые числа.

Корректирующий промпт:

Подготовка CSV для импорта (учебный шаблон)

В реальной работе заголовки берутся из экспорта вашей Zephyr-инсталляции. Ниже учебный шаблон в стиле Zephyr Scale.

Практикум: мобильный кейс

Контекст

Фича: push-уведомления о статусе заказа в мобильном приложении.

Вход: плохие требования

Приложение отправляет push о заказе.

Если пользователь разрешил, то приходит уведомление.

Если не разрешил, то как-то иначе.

Вход: уточнённые требования для практикума

Ниже зафиксирован учебный набор правил.

Push отправляется при смене статуса заказа на "Передан в доставку" и "Доставлен".

Push отправляется только если одновременно выполнены условия:

1. пользователь авторизован; 2. уведомления включены в настройках приложения; 3. уведомления разрешены в настройках ОС.

Если push не может быть отправлен из-за любого условия из пункта 2, приложение создаёт запись в центре уведомлений приложения (in-app).

In-app запись должна содержать статус заказа текстом и время события.

Промпт для ИИ: решение через таблицу решений

Таблица решений

Обозначения условий:

A авторизован.

B уведомления включены в приложении.

C уведомления разрешены в ОС.

| Rule | A | B | C | Действие | |---|---|---|---|---| | DR-01 | Да | Да | Да | Отправить push | | DR-02 | Нет | | | Создать in-app запись | | DR-03 | Да | Нет | * | Создать in-app запись | | DR-04 | Да | Да | Нет | Создать in-app запись |

Тестовые условия TCND*

| TCND ID | Условие | Техника | Trace | |---|---|---|---| | TCND-MOB-01 | Push приходит при статусе Передан в доставку при выполнении A,B,C | Таблица решений | R1,R2,DR-01 | | TCND-MOB-02 | Push приходит при статусе Доставлен при выполнении A,B,C | Таблица решений | R1,R2,DR-01 | | TCND-MOB-03 | In-app создаётся, если пользователь не авторизован | Таблица решений | R2,R3,DR-02 | | TCND-MOB-04 | In-app создаётся, если уведомления выключены в приложении | Таблица решений | R2,R3,DR-03 | | TCND-MOB-05 | In-app создаётся, если уведомления запрещены в ОС | Таблица решений | R2,R3,DR-04 | | TCND-MOB-06 | In-app запись содержит статус и время | Проверка данных | R4 |

Критерии приемки AC* (Given/When/Then)

| AC ID | Given | When | Then | Trace | |---|---|---|---|---| | AC-M1 | Пользователь авторизован, уведомления включены в приложении и разрешены в ОС, есть заказ | Статус заказа меняется на "Передан в доставку" | Приходит push-уведомление о статусе | R1,R2 | | AC-M2 | Пользователь авторизован, уведомления включены в приложении и разрешены в ОС, есть заказ | Статус заказа меняется на "Доставлен" | Приходит push-уведомление о статусе | R1,R2 | | AC-M3 | Не выполнено хотя бы одно из условий A,B,C | Статус заказа меняется на "Доставлен" или "Передан в доставку" | Push не приходит, но появляется запись in-app | R1,R2,R3 | | AC-M4 | Создана запись in-app | Пользователь открывает центр уведомлений приложения | Запись содержит текст статуса и время события | R4 |

Реестр рисков

| Risk ID | Риск | Причина | Последствие | Направление тестирования | |---|---|---|---|---| | RK-MOB-01 | Push приходит, когда условия A,B,C не выполнены | R2 | Нежелательные уведомления, жалобы пользователей | Таблица решений, негативные сценарии | | RK-MOB-02 | In-app не создаётся при невозможности push | R3 | Потеря уведомлений о статусах, рост обращений | Таблица решений, проверка fallback | | RK-MOB-03 | In-app запись не содержит время или статус | R4 | Пользователь не понимает актуальность события | Проверка данных отображения |

Чек-лист smoke

| ID | Проверка | Ожидаемый результат | Trace | |---|---|---|---| | CL-MOB-01 | A,B,C выполнены, статус "Доставлен" | Push пришёл | AC-M2 | | CL-MOB-02 | C запрещено в ОС, статус "Доставлен" | Push не пришёл; in-app запись появилась | AC-M3 | | CL-MOB-03 | Открыть центр уведомлений приложения | В записи есть статус и время | AC-M4 |

Набор тест-кейсов для регресса

| ID | Название | Предусловия | Шаги | Ожидаемый результат | Trace | Теги | |---|---|---|---|---|---|---| | TC-MOB-01 | Push при статусе Передан в доставку при выполнении A,B,C | Пользователь авторизован; уведомления включены в приложении; уведомления разрешены в ОС; есть заказ | 1. Инициировать смену статуса на "Передан в доставку" 2. Дождаться события | Push получен; текст уведомления соответствует статусу | AC-M1 | smoke;regression | | TC-MOB-02 | Push при статусе Доставлен при выполнении A,B,C | Пользователь авторизован; уведомления включены в приложении; уведомления разрешены в ОС; есть заказ | 1. Инициировать смену статуса на "Доставлен" 2. Дождаться события | Push получен; текст уведомления соответствует статусу | AC-M2 | regression | | TC-MOB-03 | In-app вместо push при запрещённых уведомлениях ОС | Пользователь авторизован; уведомления включены в приложении; уведомления запрещены в ОС; есть заказ | 1. Инициировать смену статуса на "Доставлен" 2. Открыть центр уведомлений приложения | Push не получен; есть in-app запись со статусом "Доставлен" | AC-M3 | regression;negative | | TC-MOB-04 | In-app вместо push при выключенных уведомлениях в приложении | Пользователь авторизован; уведомления выключены в приложении; уведомления разрешены в ОС; есть заказ | 1. Инициировать смену статуса на "Передан в доставку" 2. Открыть центр уведомлений приложения | Push не получен; есть in-app запись со статусом "Передан в доставку" | AC-M3 | regression;negative | | TC-MOB-05 | Формат in-app записи содержит статус и время | Есть созданная in-app запись | 1. Открыть центр уведомлений приложения 2. Открыть детали записи (если доступны) | Отображается текст статуса; отображается время события | AC-M4 | regression |

Пример ошибки ИИ и корректировка

Типовая ошибка: ИИ добавляет новый статус "Отменён" и требует отправлять по нему push.

Корректирующий промпт:

Подготовка CSV для импорта (учебный шаблон)

Мини-проверка качества артефактов перед импортом в Zephyr

Перед генерацией CSV и импортом убедитесь, что выполняются критерии:

Трассируемость:

1. каждый тест связан с R и/или AC.

Проверяемость:

1. expected result не содержит формулировок успешно/корректно без наблюдаемого признака.

Полнота по техникам:

1. веб-кейс включает BVA по диапазону. 2. мобильный кейс покрывает правила таблицы решений.

Формат импорта:

1. заголовки CSV соответствуют вашему экспортированному шаблону. 2. переносы строк внутри ячеек оформлены как \n.

Итог

После выполнения двух практикумов у вас есть полный набор артефактов, который можно повторить на любой фиче:

Требования превращаются в R* и проблемы с Evidence.

R превращаются в AC (Given/When/Then) и риски.

AC превращаются в TCND с выбранными техниками.

TCND* превращаются в чек-лист и тест-кейсы с наблюдаемыми expected results.

Валидированные тест-кейсы перепаковываются в CSV для импорта в Zephyr по строгому шаблону.

Кросс-платформенный кейс и итоговый проект: эталон и оценка

Связь с предыдущими материалами курса

В прошлых статьях вы построили конвейер:

анализ требований с фиксацией бизнес-правил R, критериев приёмки AC, вопросов и рисков;

тест-дизайн через техники покрытия (EP/BVA/таблица решений/переходы состояний) и получение тестовых условий TCND*;

промпт-контракт: контекст, источник правды, запрет домыслов, формат, Evidence/Trace;

упаковка валидированных тест-кейсов в CSV под импорт в Zephyr.

Эта статья завершает курс двумя блоками:

полноценный кросс-платформенный кейс (веб + мобильное приложение + общая бизнес-логика синхронизации);

итоговый проект с критериями оценки и эталонным результатом.

Справочные источники (терминология и форматы):

ISTQB Glossary

Gherkin Reference

Jira Cloud documentation

Zephyr Scale Cloud documentation

!Схема полного процесса от требований до импортированных тест-кейсов

Кросс-платформенный кейс

Контекст

Фича: синхронизация корзины между веб-сайтом и мобильным приложением.

Цель тестирования: доказуемо проверить, что изменения корзины на одном клиенте отражаются на другом в заданные сроки и по правилам разрешения конфликтов.

Ключевая специфика кросс-платформенного кейса:

два клиента и один серверный источник данных;

задержка синхронизации и допустимая несогласованность;

конфликтные изменения (один SKU редактируется на разных устройствах);

наблюдаемость результата должна быть определена: где именно QA видит итог (UI корзины, счётчик, список позиций).

Вход для практикума: плохие требования

Корзина должна синхронизироваться между сайтом и приложением.

Если добавить товар на сайте, он появится в приложении.

Должно быть быстро.

Если одновременно менять корзину, всё должно быть правильно.

Проблема: эти пункты почти не тестируются без уточнения идентификатора пользователя, задержек, правил конфликта и наблюдаемых критериев.

Уточнённые требования для практикума

Далее зафиксирован учебный набор требований, которые будем считать источником правды.

Синхронизация корзины выполняется по аккаунту пользователя (после логина).

При изменении корзины на одном клиенте изменения должны появиться на другом клиенте не позднее чем через 10 секунд.

Добавление позиции:

1. если на одном клиенте добавили SKU, он появляется на другом; 2. если один и тот же SKU добавлен с двух клиентов в течение 10 секунд, итоговое количество равно сумме добавлений.

Удаление позиции:

1. если SKU удалён на одном клиенте, он удаляется на другом.

Если один клиент офлайн, изменения на нём не отправляются на сервер до восстановления сети.

После восстановления сети офлайн-клиент отправляет накопленные изменения; сервер применяет их и синхронизирует второй клиент.

Извлечение правил R* с Evidence

Ниже показан формат результата анализа требований, который удобно требовать от ИИ.

| Rule ID | Правило | Evidence | |---|---|---| | R1 | Синхронизация корзины выполняется по аккаунту пользователя | "Синхронизация корзины выполняется по аккаунту пользователя" | | R2 | Время отражения изменений на втором клиенте: не позднее 10 секунд | "не позднее чем через 10 секунд" | | R3 | Добавленный SKU появляется на другом клиенте | "если ... добавили SKU, он появляется на другом" | | R4 | Конфликт добавления одного SKU с двух клиентов: количество суммируется | "итоговое количество равно сумме добавлений" | | R5 | Удалённый SKU удаляется на другом клиенте | "если SKU удалён ... он удаляется на другом" | | R6 | Офлайн-клиент не отправляет изменения до восстановления сети | "изменения ... не отправляются ... до восстановления сети" | | R7 | После восстановления сети офлайн-изменения отправляются и синхронизируют второй клиент | "после восстановления сети ... отправляет ... сервер применяет ... синхронизирует" |

Критерии приёмки AC* (Given/When/Then)

Критерии приёмки должны описывать наблюдаемый результат и быть трассируемыми к R.*

| AC ID | Given | When | Then | Trace | |---|---|---|---|---| | AC-X1 | Пользователь залогинен на веб и мобайл под одним аккаунтом, корзина пуста | На веб добавить SKU-1 qty=1 | На мобайле в корзине появляется SKU-1 qty=1 не позднее 10 секунд | R1,R2,R3 | | AC-X2 | Пользователь залогинен на веб и мобайл, корзина пуста | В течение 10 секунд: на веб добавить SKU-1 qty=1 и на мобайле добавить SKU-1 qty=2 | На обоих клиентах итог qty для SKU-1 равен 3 не позднее 10 секунд после последнего изменения | R1,R2,R4 | | AC-X3 | Пользователь залогинен на веб и мобайл, в корзине есть SKU-2 | На мобайле удалить SKU-2 | На веб SKU-2 отсутствует не позднее 10 секунд | R1,R2,R5 | | AC-X4 | Пользователь залогинен на веб и мобайл, на мобайле отключена сеть | На мобайле добавить SKU-3 qty=1, затем включить сеть | После восстановления сети SKU-3 появляется на веб не позднее 10 секунд | R6,R7,R2 |

Реестр рисков

Риски фиксируются как следствие требований, а не как фантазия про продукт.

| Risk ID | Риск | Причина | Последствие | Направление тестирования | |---|---|---|---|---| | RK-X-01 | Синхронизация происходит не по аккаунту, а по устройству | R1 | Чужая корзина или несоответствие между клиентами | тесты на один аккаунт на двух устройствах, смена аккаунта | | RK-X-02 | Нарушение SLO синхронизации (более 10 секунд) | R2 | Пользователь видит «разную корзину», теряет доверие | замеры времени, повторные прогоны, вариативность сети | | RK-X-03 | Конфликт добавления не суммируется, а перетирается | R4 | Потеря части добавлений | сценарии одновременных изменений | | RK-X-04 | Удаление не распространяется или «возрождается» | R5,R7 | Позиции появляются снова | переходы состояния позиции, проверка идемпотентности удаления | | RK-X-05 | Офлайн-изменения теряются или применяются дважды | R6,R7 | Потеря/дублирование товаров | офлайн-буфер, повторное восстановление сети |

Тест-дизайн кросс-платформенного кейса

Наблюдаемость результата

Для каждого теста фиксируйте точку наблюдения:

состав корзины (список SKU);

количество по SKU;

время фиксации изменения на каждом клиенте (таймер/замер).

Если в продукте нет встроенного индикатора времени, QA измеряет время внешне: фиксирует (момент действия) и (момент появления изменения на втором клиенте), затем сравнивает с 10 секундами.

Тестовые условия TCND* и техники

| TCND ID | Тестовое условие | Техника | Trace | |---|---|---|---| | TCND-X-01 | Базовая синхронизация добавления SKU веб -> мобайл в пределах 10 секунд | переходы состояния + тайминг | AC-X1 | | TCND-X-02 | Конфликт добавления одного SKU с двух клиентов: итоговое количество = сумма | комбинации условий + тайминг | AC-X2 | | TCND-X-03 | Синхронизация удаления SKU мобайл -> веб в пределах 10 секунд | переходы состояния + тайминг | AC-X3 | | TCND-X-04 | Офлайн: изменение не уходит до восстановления сети, затем синхронизируется | переходы состояния + негативный сценарий | AC-X4 | | TCND-X-05 | Идемпотентность применения офлайн-изменений при повторном восстановлении сети | негативный сценарий | R6,R7 |

Чек-лист smoke

| ID | Проверка | Ожидаемый результат | Trace | |---|---|---|---| | CL-XPL-01 | Веб: добавить SKU-1 qty=1 при залогиненном мобайле | На мобайле SKU-1 qty=1 ≤ 10 сек | AC-X1 | | CL-XPL-02 | Мобайл: удалить SKU-2 при открытой корзине на веб | На веб SKU-2 отсутствует ≤ 10 сек | AC-X3 | | CL-XPL-03 | Офлайн мобайл: добавить SKU-3, затем включить сеть | На веб SKU-3 появился ≤ 10 сек после включения сети | AC-X4 |

Набор тест-кейсов (регресс)

Шаблон: название + предусловия + шаги + наблюдаемый expected result + Trace.

| ID | Название | Предусловия | Шаги | Ожидаемый результат | Trace | Теги | |---|---|---|---|---|---|---| | TC-XPL-01 | Веб добавление отражается на мобайле в пределах 10 сек | Один аккаунт на веб и мобайл; корзина пуста; оба клиента онлайн | 1. На веб добавить SKU-1 qty=1 2. Засечь время 3. На мобайле открыть корзину/обновить | На мобайле отображается SKU-1 qty=1; время появления ≤ 10 сек | AC-X1 | smoke;regression | | TC-XPL-02 | Конфликт: суммирование qty при добавлении с двух клиентов | Один аккаунт на веб и мобайл; корзина пуста; оба клиента онлайн | 1. На веб добавить SKU-1 qty=1 2. В течение 10 сек на мобайле добавить SKU-1 qty=2 3. Открыть корзину на обоих клиентах | Итог qty SKU-1 = 3 на веб и на мобайле; расхождение исчезает ≤ 10 сек после последнего изменения | AC-X2 | regression;negative | | TC-XPL-03 | Удаление на мобайле отражается на веб в пределах 10 сек | Один аккаунт на веб и мобайл; в корзине есть SKU-2 qty=1; оба клиента онлайн | 1. На мобайле удалить SKU-2 2. Засечь время 3. На веб открыть корзину/обновить | На веб SKU-2 отсутствует; время обновления ≤ 10 сек | AC-X3 | smoke;regression | | TC-XPL-04 | Офлайн мобайл: изменения не синхронизируются до восстановления сети | Один аккаунт на веб и мобайл; корзина пуста; мобайл офлайн; веб онлайн | 1. На мобайле добавить SKU-3 qty=1 2. На веб открыть корзину | На веб SKU-3 отсутствует до восстановления сети на мобайле | R6 | regression;negative | | TC-XPL-05 | Офлайн мобайл: после восстановления сети изменения синхронизируются на веб | Условия как в TC-XPL-04, SKU-3 добавлен на мобайле офлайн | 1. На мобайле включить сеть 2. Засечь время 3. На веб открыть корзину/обновить | На веб появляется SKU-3 qty=1; время появления ≤ 10 сек после включения сети | AC-X4 | regression | | TC-XPL-06 | Повторное восстановление сети не дублирует офлайн-изменения | Один аккаунт; корзина пуста; мобайл офлайн; веб онлайн | 1. На мобайле добавить SKU-4 qty=1 2. Включить сеть 3. Дождаться синхронизации 4. Снова выключить и включить сеть 5. Проверить корзину на веб | На веб SKU-4 qty остаётся 1; не появляется qty=2 | R6,R7 | regression;negative |

Матрица трассируемости

| Элемент | Покрытие тестами | |---|---| | AC-X1 | TC-XPL-01 | | AC-X2 | TC-XPL-02 | | AC-X3 | TC-XPL-03 | | AC-X4 | TC-XPL-05 | | R6 | TC-XPL-04, TC-XPL-06 | | R7 | TC-XPL-06 |

Промпты для ИИ: кросс-платформенный кейс

Промпт: извлечь правила и проблемы (без домыслов)

Промпт: превратить R в AC и сразу потребовать трассируемость

Промпт: тест-дизайн (условия + техники + ограничения на объём)

Типовые ошибки ИИ в кросс-платформенном кейсе и исправление

Ошибка: ИИ придумывает идентификатор синхронизации

Неверный фрагмент:

"Синхронизация выполняется по deviceId, чтобы работало без логина".

Почему ошибка: в источнике правды синхронизация по аккаунту пользователя (логин).

Корректирующий промпт:

Ошибка: ИИ «размывает» критерий 10 секунд

Неверный expected result:

"Изменения появляются достаточно быстро".

Почему ошибка: нарушена проверяемость.

Корректирующий промпт:

Подготовка Zephyr/Jira для кросс-платформенного кейса

Пример структуры папок Zephyr

| Папка | Назначение | |---|---| | XPL/Cart Sync | Все тесты синхронизации корзины | | XPL/Cart Sync/Offline | Тесты офлайн-логики | | XPL/Cart Sync/Conflicts | Конфликты и конкурентные изменения |

Пример структуры требований в Jira

| Тип | Пример | Комментарий | |---|---|---| | Story | XPL-101 | "Cart synchronization between Web and Mobile" | | Sub-task | XPL-102 | "Offline changes sync" |

Практическое правило: ключ Jira добавляйте в Objective или в начало TestScript строкой Trace: XPL-101; AC-X2.

CSV для импорта в Zephyr (учебный шаблон)

Перед реальным импортом заголовки берутся из экспорта вашей инсталляции Zephyr и считаются источником правды.

Итоговый проект: задание, входные данные, критерии оценки, эталон

Описание задания

В итоговом проекте вы должны пройти весь конвейер на одном выбранном кейсе и подготовить артефакты, пригодные для импорта в Zephyr.

Допустимые кейсы:

веб-кейс (фильтр каталога по цене);

мобильный кейс (push-уведомления о статусе заказа);

кросс-платформенный кейс (синхронизация корзины веб+мобайл).

Входные данные

Входной пакет для проекта состоит из четырёх частей.

Требования (сырой текст) выбранного кейса.

Уточнённые требования выбранного кейса (после ваших вопросов).

Ограничения:

1. нельзя добавлять сущности и правила, которых нет в уточнённых требованиях; 2. если данных нет, это фиксируется как Вопросы, а не выдумывается.

CSV-шаблон:

1. заголовки и порядок столбцов считаются источником правды; 2. разделитель запятая; 3. переносы строк в полях представлены как \n.

Обязательные артефакты на сдачу

Таблица правил R* с Evidence.

Таблица проблем требований и список Вопросы.

Критерии приёмки AC в Given/When/Then с Trace на R.

Реестр рисков.

Таблица тестовых условий TCND* с техниками и трассируемостью.

Чек-лист smoke.

Набор тест-кейсов (минимум 6, максимум 12): предусловия, шаги, наблюдаемый expected result, Trace, теги.

CSV для импорта в Zephyr, сформированный строго по шаблону.

Критерии оценки

Оценка строится по качеству QA-артефактов, а не по объёму текста.

| Критерий | Что проверяется | Типичные ошибки | |---|---|---| | Доказуемость | у R* есть Evidence, у тестов есть Trace | домыслы ИИ без оснований | | Проверяемость | expected result наблюдаемый и однозначный | "успешно", "корректно" без признака | | Полнота покрытия | AC* покрыты тестами, учтены риски и ключевые техники | только позитивные сценарии | | Консистентность | единые статусы/термины/форматы | разные термины для одного объекта | | Импортопригодность | CSV соответствует шаблону: заголовки, порядок, кавычки, \n | разное число столбцов, сломанные кавычки |

Шкала зачёта (практическая)

Зачёт: соблюдены доказуемость, проверяемость, CSV проходит формальную валидацию.

Зачёт с замечаниями: есть мелкие проблемы консистентности/тегов/приоритетов, но трассируемость и импорт сохраняются.

Незачёт: есть домыслы без источника, expected results непроверяемы, CSV нарушает шаблон.

Эталонный результат (фрагмент)

Ниже приведён фрагмент эталона для кросс-платформенного кейса, показывающий требуемый уровень точности.

#### Фрагмент R* с Evidence | Rule ID | Правило | Evidence | |---|---|---| | R2 | Изменения появляются на другом клиенте не позднее 10 секунд | "не позднее чем через 10 секунд" | | R4 | Конфликт добавления одного SKU: итоговое количество = сумма | "итоговое количество равно сумме добавлений" |

#### Фрагмент тест-кейса | ID | Название | Предусловия | Шаги | Ожидаемый результат | Trace | Теги | |---|---|---|---|---|---|---| | TC-XPL-02 | Конфликт: суммирование qty при добавлении с двух клиентов | Один аккаунт; корзина пуста; оба клиента онлайн | 1. На веб добавить SKU-1 qty=1 2. В течение 10 секунд на мобайле добавить SKU-1 qty=2 3. Проверить корзину на обоих клиентах | На веб и мобайле qty SKU-1 = 3; итог достигается не позднее 10 секунд после последнего изменения | AC-X2 | regression;negative |

#### Фрагмент CSV

Итог статьи

После этой статьи у вас есть завершающий шаблон работы:

кросс-платформенная фича переводится в проверяемые R и AC без домыслов;

тест-дизайн учитывает конфликты, офлайн и измеримый критерий времени;

тесты оформляются с трассируемостью и наблюдаемыми expected results;

результат перепаковывается в CSV по жёсткому шаблону и готов к импорту в Zephyr.