QA из Cloud.ru сократил задачу по автотестам с полудня до 1–1,5 часов с помощью OpenSpec

Агент написал тесты, код аккуратный, pytest показывает зелёное. Можно закрывать задачу? Не факт. QA-инженер Cloud.ru рассказал, как после нескольких таких случаев собрал процесс из четырёх агентов и спецификаций. Теперь он тратит больше времени на требования и риски, чем на сам код.

Зелёный тест, который ничего не доказывает

На проекте есть функциональность публикации структуры документации в Git. Если при повторной публикации из структуры пропадает секция, соответствующий файл должен удалиться из репозитория. Агент написал тест test_update_structure_removes_orphan_doc_file. Он публикует структуру с секциями overview и setup, затем публикует её повторно без setup, клонирует репозиторий и проверяет, что файла setup нет.

Выглядит разумно: проверяется реальное состояние Git, а не только ответ API. Но перед удалением агент ни разу не убедился, что файл там был. Наличие документа он подтверждал через get_repowiki_docs(), а этот метод может возвращать метаданные, не заглядывая в сам репозиторий. Если при первой публикации файл не появился, тест всё равно пройдёт: после второй публикации его тоже нет. Тест проверяет конечное состояние, но не сам переход «файл был — файла нет».

Самопроверка агента-разработчика этого не заметила: он анализировал логику теста, но не ставил экспериментов. Проблему нашёл другой агент, ревьювер. После этого в тест добавили шаг с repowiki_repo_clone() as clone_before, который проверяет наличие файла до повторной публикации. Тот же класс ошибок встречается и в простых случаях: агент проверяет HTTP 400, но не смотрит на структуру тела ошибки.

Как устроен процесс

Автор открывает Claude Code и отдаёт главному агенту, оркестратору, номер задачи из Jira. Правила описаны в файле CLAUDE.md в репозитории: какие есть агенты, за что они отвечают, как переходить между этапами и когда нужно подтверждение человека. Сейчас агентов четыре:

• test-planner исследует задачу и существующие тесты и создаёт OpenSpec change. В нём лежат proposal.md (зачем), design.md (подход и ограничения) и tasks.md (конкретные шаги). Затем план проходит openspec validate --strict.
• test-qa-writer реализует тесты по tasks.md и отмечает выполненные пункты.
• test-reviewer сверяет реализацию со спецификацией и архитектурными договорённостями. Тесты он сам не запускает, работает только с кодом и артефактами.
• docs-writer обновляет документацию.

Человек подключается в двух местах. Первое — после плана: он проверяет, правильно ли агент понял задачу, нет ли пропущенных случаев и вписывается ли решение в архитектуру тестового проекта. Спорные вопросы по бизнес-логике он уточняет у разработчиков. Второе — после ревью: оркестратор приносит заключение, и решение о доработке или архивации принимает человек.

В change остаются qa-report.md и review.md. Поэтому у задачи сохраняется история: что планировали, что сделали и какие замечания возникали.

Проверка на «не фигню»

Помимо ревью, автор делает реальные прогоны и проверяет чувствительность тестов. Например, намеренно меняет ожидаемое значение в assert и смотрит, падает ли тест. Это не полноценное мутационное тестирование сервиса, а дешёвый способ убедиться, что утверждения что-то проверяют.

Есть и честная оговорка. Разработчик и ревьювер могут работать на одной модели. Разделение ролей не делает проверку полностью независимой, но меняет позицию и критерии оценки. Именно такая схема поймала историю с файлом setup.

Что из этого взять себе

Автор оценивает выигрыш так: вместо половины рабочего дня задача занимает около часа-полутора, причём часть работы агенты делают, пока он занят другим. Оценка приблизительная, и это опыт одного человека на одном проекте. Для мелких задач он сам допускает упрощение процесса.

Практические выводы для команд, которые делегируют тесты агентам:

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

В исходной статье дальше разбирается кейс с CRUD для Git-тегов: было три теста на GET /tags, которые проверяли только поле name, а для POST и DELETE покрытия не было. Но главный вывод виден уже по описанию процесса. Агенты забирают на себя реализацию, а за требования и итоговое качество по-прежнему отвечает человек.