Восемь требований разложены на восемнадцать проверок — и три требования не закрыты

Тест-план релиза, матрица трассируемости и результат прогона: что проверено, чем и что осталось.

Что это

Агент пишет не «список проверок», а план с методом и следом

Чат-бот выдаст список идей. Агент разворачивает требование в проверку с ожидаемым результатом, помечает, чем проверяется — запросом, разбором HTML, SQL или руками, — и заполняет матрицу: требование → проверка → результат. По матрице видно, какое требование осталось без проверки.

Вход и выход

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

Вход — требование

Восемь ворот приёмки сайта: код ответа, один заголовок, длина title, описание, ссылки, карта, 404, редирект.

  • Прогон — работает

    Сто сорок четыре адреса из карты сайта обойдены за 7,2 секунды: 143 ответа 200 и один 404 на адрес, которого быть не должно.

  • Разбор HTML — работает

    Заголовок, описание и ссылки разобраны на каждой странице; расхождения посчитаны, а не названы на глаз.

  • Матрица — работает

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

  • Тест-менеджер — подключим

    Яндекс Трекер или YouGile: очередь и токен с правом задач, один день. Тогда прогон сам заводит дефекты.

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

Требования — ворота приёмки сайта; результат — фактический прогон 09.11.2026, не оценка

  1. 1

    Тест-план релиза

    Восемь требований, восемнадцать проверок: метод, приоритет, кто выполняет.

  2. 2

    Нарушения по требованиям

    Сколько проверок не прошло и на скольких адресах — по каждому требованию.

  3. 3

    Матрица и итог

    Трассируемость требование → проверка → результат и что это значит для релиза.

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

Разворачивает требованиеАгент: требование → проверки с ожидаемым результатом. Человек: подтверждает, что считается браком.
Ставит методАгент: запрос, разбор разметки, SQL, руками — по характеру проверки. Человек: согласует, что автоматизируем.
Проставляет приоритетАгент: блокирующее, важное, косметика — по влиянию на пользователя. Человек: двигает приоритет под срок релиза.
Заполняет матрицуАгент: результат по каждой проверке и адресу. Человек: разбирает спорные случаи.
Пишет выводАгент: какие требования не закрыты и что блокирует. Человек: подписывает готовность.

Сценарий: от требования до матрицы

  1. 1

    Собрать требования

    Ворота приёмки из регламента, ТЗ и канона: что вообще считается «сделано».

  2. 2

    Разложить

    Каждое требование — в проверки с ожидаемым результатом и границей «проходит/нет».

  3. 3

    Выбрать метод

    Запрос к серверу, разбор разметки, SQL-запрос, сравнение с макетом — по характеру.

  4. 4

    Прогнать

    Обход адресов и разбор ответов; результат — построчно, с кодом и временем.

  5. 5

    Заполнить матрицу

    Требование → проверка → адрес → результат → дефект.

  6. 6

    Выход

    План и матрица файлами; незакрытые требования — списком, до релиза.

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

Три источника требований, один — результат

  • Ваш регламент

    Что считается браком, какие ворота приёмки и какой приоритет у каждого требования.

  • ТЗ и макеты

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

  • Живой стенд

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

  • Файл

    Когда стенда нет: чек-лист и матрица собираются из ТЗ, результат заполняет человек.

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

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

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

  • Требование противоречит другому

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

  • Требование нельзя проверить техникой

    Агент пишет «руками» и что именно смотреть; не выдаёт это за автоматическую проверку.

  • Стенд недоступен

    Матрица заполняется планом, результат остаётся пустым — «не проверено», а не «проходит».

  • Спор о браке

    Агент приносит факт (код, разметку, время) и ждёт решения; сам браком не объявляет.

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

  • «У нас есть тест-план в таблице»

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

  • «Это же можно написать быстрее руками»

    План пишется один раз, прогон — каждый релиз; матрица заполняется результатом, а не памятью.

  • «Кто отвечает за пропущенный дефект?»

    Видно, какое требование не проверялось и почему: пустая ячейка в матрице — это решение, а не случайность.

  • «Нужен ли тест-менеджер?»

    Нет: план и матрица приходят файлом. Тест-менеджер нужен, чтобы прогон сам заводил дефекты.

  • «А если требований нет?»

    Тогда первый артефакт — список ворот приёмки с вопросами к ТЗ; он же основа плана.

Границы

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

Не объявляет дефект без факта: код, разметка, время или запись — иначе «наблюдение». Не придумывает покрытие: пустая ячейка значит «не проверено». Не подписывает готовность к релизу — это решение человека. В тестовые данные не тянет настоящие персональные данные (152-ФЗ). Гарантий и превосходных степеней в отчёте нет — ст. 5 ФЗ-38.

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

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

С одного релиза: пришлите ворота приёмки и адрес стенда — вернём план, матрицу и результат прогона.

Сколько это занимает?

Прогон ста сорока четырёх адресов — семь секунд; разбор и матрица — работа агента, не ваша.

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

Список требований (или ТЗ) и доступ к стенду. Тест-менеджер — по желанию, один день.

Чем это отличается от чек-листа в таблице?

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

Где хранятся результаты?

В вашем аккаунте; в файл попадают только адреса и факты, без персональных данных.

Роль целиком

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

Роли

Собрать тест-план одного релиза

Пришлите ворота приёмки и адрес стенда — вернём план, матрицу трассируемости и результат прогона.