От требований заказчика до тест-кейсов: как не потерять ни одного требования

Где теряются требования

Знакомая история. Заказчик рассказал на созвоне, аналитик записал в документ, разработчик прочитал по-своему, тестировщик проверил то, что увидел в готовом продукте. Каждый передал дальше чуть меньше, чем получил. Потерянное требование всплывает на приёмке — там, где исправлять дороже всего.

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

В Цифровом мозге требования, критерии приёмки и тест-кейсы живут в одной задаче и связаны между собой. ИИ берёт на себя черновую работу на каждом шаге, а решения принимают люди. Разберём цепочку на примере.

Шаг 1. Аналитик записывает требования заказчика

Аналитик заводит задачу и переносит в описание бизнес-требования так, как их сформулировал заказчик, — пунктами БТ1, БТ2, БТ3. Например, для онлайн-записи в салон красоты:

БТ1. Клиент записывается на услугу через сайт.

БТ2. Мастер видит свои записи на день.

БТ3. Клиенту приходит напоминание о визите.

Так выглядит почти любое первое ТЗ: понятно, чего хочет заказчик, но непонятно, как это проверить и где границы.

Шаг 2. «Проверить требования (ИИ)»

Над описанием задачи — кнопка «Проверить требования (ИИ)». ИИ читает текст как опытный аналитик требований и возвращает две вещи.

Замечания с цитатой из текста. Их четыре вида:

• Неясно — формулировку можно понять по-разному.
• Противоречие — два места текста спорят друг с другом.
• Пропущено — ничего не сказано про ошибки ввода, права доступа, граничные случаи, нефункциональные требования.
• Структура — требование размазано по тексту или смешано с другим.

Описание, переписанное по разделам — например, «Цель», «Требования», «Ограничения», «Вне рамок». Исходный и новый текст стоят рядом: «Было» и «Стало».

Для примера выше вопросы могли бы быть такими: за сколько до визита напоминать и каким способом? Может ли клиент сам отменить или перенести запись? Что видит клиент, если свободного времени нет? Видит ли мастер записи коллег?

Главное — ИИ не угадывает за заказчика. Чего нет в тексте, он не дописывает в описание, а выносит в замечания вопросом. И ничего не сохраняет сам: описание меняется только по кнопке «Применить», а прежний вариант остаётся в истории задачи.

Шаг 3. Аналитик уточняет у заказчика

Список замечаний — готовая повестка для созвона. Не «давайте пройдёмся по ТЗ», а конкретные вопросы с цитатами из текста. Ответы аналитик дописывает в описание задачи. Проверку можно запустить ещё раз — и убедиться, что неясностей не осталось.

Шаг 4. Критерии приёмки — «Сгенерировать ИИ»

Во вкладке «Содержание» под описанием — блок «Критерии приёмки». Критерий — проверяемое утверждение о результате: что должно быть правдой, чтобы задачу можно было выпустить. Не «запись должна быть удобной», а «клиент, выбравший занятое время, видит сообщение, что время уже занято».

Кнопка «Сгенерировать ИИ» рядом с блоком предлагает критерии по названию и описанию задачи. Правила строгие: только то, что следует из текста, без повторов уже записанных. Если по какому-то месту проверяемый критерий не сформулировать, ИИ не придумывает его, а показывает отдельным списком «что уточнить». Аналитик отмечает подходящие критерии и добавляет — в задаче появляются AC 1, AC 2, AC 3:

• AC 1. Клиент выбирает услугу, мастера и свободное время и получает подтверждение записи.
• AC 2. Занятое время не показывается в форме записи.
• AC 3. Мастер видит в расписании на день только свои записи.
• AC 4. Клиент получает напоминание за 24 часа до визита.

Последний критерий появился только потому, что на шаге 3 заказчик ответил на вопрос «за сколько напоминать». Без этого вопроса БТ3 так и остался бы непроверяемым.

Шаг 5. Тестировщик: кейсы по критериям

Тестировщик открывает ту же задачу, вкладку «Тестирование». Там — покрытие: те же критерии приёмки, а под каждым — его тест-кейсы и чек-листы. Критерий, под которым пусто, подписан «Критерий не покрыт тест-кейсами».

Кнопка «Сгенерировать ИИ» в блоке «Тест-кейсы задачи» сначала спрашивает, что составить: тест-кейсы с шагами «Действие — Ожидаемый результат» или короткие чек-листы. Затем предлагает их по описанию задачи и критериям приёмки. Тестировщик отмечает нужные и сохраняет. Кейсы ложатся в раздел библиотеки с названием задачи и сразу привязаны к задаче и к своим критериям — покрытие заполняется на глазах.

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

• «Пройти» на кейсе — и у каждого шага отметка «Успешно», «Провал», «Блок» или «Пропущен» с комментарием. Скриншот вставляется по Ctrl+V.
• «Завести баг» на проваленном шаге создаёт баг с описанием шага, уже связанный с задачей.
• «Готовность по тестам» в правой панели задачи показывает, сколько кейсов прошли успешно.
• «План тестирования» собирает все кейсы задачи, а «Пройти следующий» ведёт по непройденным подряд.

Почему требование не теряется

Цепочка «требование → критерий приёмки → тест-кейс → прохождение» видна в одной задаче, а не собирается из трёх вкладок браузера:

• Непонятное в ТЗ всплывает до разработки, а не на приёмке.
• Каждое уточнение заказчика записано в задаче, прежние версии описания хранятся в истории.
• Критерий без проверки виден сразу — по подписи «Критерий не покрыт тест-кейсами».
• Провал теста становится багом, связанным с задачей, а не сообщением в чате, которое утонет к вечеру.

Скорость здесь не в ущерб качеству. ИИ пишет черновики — замечания, критерии, кейсы, — на которые вручную уходят часы. Решения остаются за человеком: что применить, какие критерии взять, какие кейсы сохранить.

Кому это подходит

• Команде разработки, где аналитик, разработчик и тестировщик работают с одними и теми же задачами.
• Студии или фрилансеру, которые сдают работу заказчику по критериям приёмки и хотят закрыть спор «мы так не договаривались».
• Тестировщику, которому нужна библиотека кейсов рядом с задачами: разделы, тестовые планы для регресса и импорт кейсов из TestRail, Test IT, Qase, Zephyr и Xray.

Что нужно, чтобы попробовать

Тест-кейсы, чек-листы, прохождения и тестовые планы доступны на всех тарифах, включая бесплатный. Чтобы аналитик и тестировщик работали в одном пространстве вдвоём и больше, нужен тариф Про — на бесплатном один участник. ИИ-функции — проверка требований, генерация критериев приёмки и тест-кейсов — работают на тарифе Про: одна генерация списывает один ход ИИ, в тариф входит 100 ходов в месяц. Чтобы ИИ заработал, администратор пространства один раз даёт согласие на передачу текста задач сервису ИИ.

Подробно о разделе — в руководстве по тестированию.