Шесть мест, где требование расходится с системой — и вопросы до первого прогона

Реестр требований: источник, что требует, что на практике, вопрос владельцу и риск.

Что это

Агент не пересказывает ТЗ, а находит места, где его нельзя проверить

Требование «описание 140–160 знаков» проверяемо, а «страница должна быть удобной» — нет. Агент раскладывает требования на проверяемые и нет, сверяет с фактическим поведением системы и формулирует вопрос, на который должен ответить человек: иначе тест-план проверяет не то.

Вход и выход

Что сверено в этой сессии, а что подключим

Вход

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

  • Сверка — работает

    Сто сорок четыре адреса: длина заголовка, описание, число заголовков, вес, время.

  • Противоречия — найдены

    Шесть мест: заголовок 88 против 60 в каноне, описание 87 против 140, потолок блоков снят, числа, латиница, тип ссылки.

  • Вопросы — сформулированы

    У каждого расхождения вопрос и владелец: канон, разработка или редакция.

  • Figma — подключим

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

Что открывается: реестр требований, вопросы и риск

Расхождения настоящие: канон и регламент сверены с фактами прогона 09.11.2026

  1. 1

    Реестр требований

    Требование, источник, что требует, что на практике — построчно.

  2. 2

    Вопросы по местам

    Сколько расхождений в каждой области и какой риск, если не ответить.

  3. 3

    Вопросы и решения

    Кому вопрос, что будет считаться нормой после ответа, как это попадёт в тест-план.

Файлы

Что агент делает и что остаётся человеку

Читает требованиеАгент: выписывает формулировку и источник. Человек: подтверждает, что это действующее требование.
Проверяет на проверяемостьАгент: есть ли измеримый признак — знаки, код, секунды. Человек: решает, чем заменить неизмеримое.
Сверяет с фактомАгент: что система делает на самом деле. Человек: решает, баг это или устаревшее требование.
Формулирует вопросАгент: один вопрос и варианты ответа. Человек: отвечает и фиксирует норму.
Обновляет планАгент: переписывает проверки под ответ. Человек: принимает новый тест-план.

Сценарий: от ТЗ до тест-плана

  1. 1

    Сбор

    Требования из канона, регламента, ТЗ и макета — с указанием источника.

  2. 2

    Разбор

    Каждое требование: проверяемо или нет, чем измеряется, где граница.

  3. 3

    Сверка

    Фактическое поведение: прогон и разметка, а не мнение.

  4. 4

    Противоречия

    Где требование и факт расходятся — вопрос и риск.

  5. 5

    Ответы

    Человек отвечает; норма фиксируется в тест-плане с датой.

  6. 6

    Выход

    Реестр требований и вопросов; тест-план — только по отвеченным.

Откуда данные

Три входа разбора

  • Требования

    Канон ворот, регламент заказчика, ТЗ: что считается нормой и откуда это известно.

  • Макет

    Что нарисовано: состояния, тексты, форматы — из макета, а не из головы.

  • Живая система

    Что реально отдаёт сервер: код, разметка, время — фактическая сторона сверки.

  • Файл

    Если макета нет в доступе: скриншоты и выгрузка стилей — третий законный вход.

Что читаем, что пишем и что нужно от вас

Что подключим

Норма, на которую опирается работа

Краевые случаи

Где решает человек, а не агент

  • Требование неизмеримо

    Агент не придумывает числовой порог: он предлагает вариант и ждёт ответа.

  • Требование устарело

    Агент показывает факт и дату; снять требование может только владелец.

  • Два требования противоречат

    Агент приносит пару и влияние каждого; приоритет — за человеком.

  • Макета нет

    Агент строит план по опубликованной странице и помечает «сверено с фактом, не с макетом».

Что обычно возражают

  • «Требования и так понятны команде»

    В каноне шесть мест расходятся с фактом: без ответа тест-план проверяет догадку.

  • «Это работа аналитика, а не тестировщика»

    Тестировщик первым упирается в неизмеримое требование — на прогоне.

  • «Зачем вопросы, дайте просто список»

    Список без ответов — это спор через месяц; вопрос с владельцем закрывает его сейчас.

  • «У нас нет ТЗ»

    Тогда источник — регламент и опубликованная страница; так тоже работает, и это видно в файле.

  • «Сколько времени это займёт?»

    Один проход по требованиям; вопросы формулируются один раз и живут в реестре.

Границы

Чего агент не делает

Не додумывает порог там, где требование неизмеримо, и не объявляет требование недействительным. Не правит ТЗ и макет. Не считает расхождение багом, пока не отвечен вопрос «что норма». Не выдаёт разбор по опубликованной странице за сверку с макетом. Гарантий нет — ст. 5 ФЗ-38.

Вопросы, которые задают первыми

С чего начать?

Пришлите ТЗ или канон приёмки — вернём реестр требований, вопросов и рисков.

Что нужно от нас?

Документ требований и адрес стенда. Макет — по доступу, два дня.

Это заменит аналитика?

Нет: агент находит неизмеримое и противоречивое, решение и приоритет — за человеком.

Что если требований нет вообще?

Собираем ворота приёмки из регламента и практики, помечая каждое как «наше предложение».

Как это связано с тест-планом?

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

Роль целиком

Что ещё берёт на себя агент

Роли

Разобрать требования одного релиза

Пришлите ТЗ или ворота приёмки — вернём реестр противоречий и вопросы с владельцами.

Telegram
MAX
Открыть чат