Ревью набора: покрытие, риск и ложная уверенность

Что именно покрывает набор

Фраза «сгенерировано 50 тестов» говорит о размере документа. Чтобы оценить покрытие, определите знаменатель: правила R1–R9, классы длин, ветви таблицы решений или переходы. Затем свяжите элементы модели с конкретными проверками. Разные модели отвечают на разные вопросы; покрытие всех ветвей таблицы не означает проверку всех строковых границ.

Рядом с тестом запишите статус: предложен, отревьюирован, выполнен, пройден или провален. ИИ способен составить план без доступа к стенду, но не должен выдавать этот план за прогон. Успешное выполнение также требует оракула: HTTP 200 у запроса, который должен отказать, не является положительным результатом теста. Коды ответа и статусы проверки — разные сущности.

Фрагмент матрицы

Разберите повторения и пропуски

Пять проверок «ввести корректный title» с длинами 10,20,30,40,50 могут принадлежать одному классу и не давать новой информации о границах. Это не повод автоматически удалить всё кроме одной: разные наборы текста могут проверять кодирование, пробелы и раскладку. Сначала укажите цель каждого примера. Если различия не связаны с риском или правилом, обозначьте дубликат.

Обратный случай — похожие действия, которые нельзя объединять. Автор-user и editor-неавтор нужны для проверки OR, хотя оба получают 200. Чтение draft и publish того же draft проверяют разные права. При ревью модели просите объяснить, какую потенциальную ошибку обнаруживает каждая строка; это полезнее просьбы «сократи до 10 тестов».

Приоритет должен помогать выбрать следующий шаг

Для OrbitDesk утечка чужого draft имеет понятное влияние: содержание станет доступно тому, кому оно не разрешено. Ошибка длины может блокировать создание допустимой задачи или допускать недопустимую. Эти последствия обосновывают ранние проверки, но не доказывают частоту дефекта. Не назначайте искусственный числовой риск как будто он измерен. Запишите предположение и данные, которые могли бы его подтвердить: изменение серверного middleware, новый валидатор, история похожих дефектов.

Если времени мало, назовите проверяемый срез: права чтения, ветви публикации и критические границы. Явно оставьте вопросы о сетевой неопределённости и конкурентном редактировании вне прогона. Это честная область результата, а не недостаток отчёта.

Практический протокол ревью

Сохраните исходный запрос, версию правил и ответ ассистента. Отметьте неподтверждённые ожидания, выполнимость данных, пропущенные предусловия и привязку к оракулу. Исправленную матрицу сравните с исходной: какой пробел закрыт и какое лишнее правило удалено? Второй ассистент может помочь найти несогласованность, но два похожих ответа не являются независимым подтверждением истины. Последнее решение принимает человек по правилам и наблюдениям.

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