К аналитикам требования минимальные - фиксировать договоренности команды на груммингах в любом формате, следить за актуальностью требований к фиче и прорабатывать возникшие вопросы. Если этого не делать - у команды будут проблемы в любом случае. Какого то особого формата аналитике не требуется. Opus очень хорошо анализирует требования и раскладывает по шаблонам.
Блок 10 это скорей мои мечты, до которых еще далеко. Рано рекламировать.
Да, это правильный путь, если база знаний лежит в векторе это просто замечательно. Не экспериментировал с этим т.к нет ресурсов чтобы поднять стек, в рамках проекта работаю только с текстом.
Про глобальный контекст лучше мне написать отдельную статью)
Глобальный контекст - это не просто взять и "скормить" LLM-ке всю информацию которую мы нашли по проекту. Глобальный контекст нужно готовить, до недавнего времени мы делали это руками, но сейчас есть отдельный скилл который этим занимается.
На вход мы подаем как минимум - репозитории с кодом объекта тестирования. Если объект состоит из нескольких микросервисов, репозиториев может быть много. Так же можно подложить что угодно еще, например описание пользовательских сценариев.
На выходе мы получаем информацию подготовленную в соответствии со стандартными шаблонами:
-Бизнес спецификация - бизнесовое описание функций + сценарии
-Техническая спецификация - архитектура сервисов и их взаимодействия
-API спецификация по каждому сервису
-Если уже есть тескейсы, то описание правильного поведения системы на основе кейсов
В итоге мы имеем довольно компактное, структурированное, и стандартизированное описание объекта тестирования.
Дальше уже остальные скиллы держат этот как контекст, для принятия решений.
Действительно, мы сейчас отлаживаемся на "простых" проектах. Но думаю задача тестирования "больших" проектов вполне себе решаемая, даже с текущем уровнем технологий. Конечно нужно будет подумать про оптимизации для экономии контекстного окна. Можно дробить задачи тестирования, можно декомпозировать объект тестирования, управлять загрузкой глобального контекста, разделять задачи на несколько субагентов (у каждого субагента свое личное окно контекста, у opus 1 000 000 токенов)
Смотря что считать за процесс. Вникать в тему использовании ИИ в тестировании я начал в октябре 2025. Это были эксперименты с разными участками QA на разных стеках, так же в процессе в голове собирались идеология и архитектура проекта. Примерно с февраля я начал уже плотно заниматься реализацией на Claude Code, через 2 недели был готов MVP описанного процесса, но после этого было еще бесчисленное количество фиксов и улучшений. Работа с анализом результатов ведется на постоянной основе.
Интересно какими моделями был опыт? Уровень модели сильно влияет на результат. Например Sonnet уже работает заметно хуже с текстами. Так же необходимо применять хорошие практики для улучшения результата, например вот https://medium.com/@ashleyha/i-mastered-the-claude-code-workflow-145d25e502cf
К аналитикам требования минимальные - фиксировать договоренности команды на груммингах в любом формате, следить за актуальностью требований к фиче и прорабатывать возникшие вопросы. Если этого не делать - у команды будут проблемы в любом случае. Какого то особого формата аналитике не требуется. Opus очень хорошо анализирует требования и раскладывает по шаблонам.
Блок 10 это скорей мои мечты, до которых еще далеко. Рано рекламировать.
Да, это правильный путь, если база знаний лежит в векторе это просто замечательно. Не экспериментировал с этим т.к нет ресурсов чтобы поднять стек, в рамках проекта работаю только с текстом.
Про глобальный контекст лучше мне написать отдельную статью)
Глобальный контекст - это не просто взять и "скормить" LLM-ке всю информацию которую мы нашли по проекту. Глобальный контекст нужно готовить, до недавнего времени мы делали это руками, но сейчас есть отдельный скилл который этим занимается.
На вход мы подаем как минимум - репозитории с кодом объекта тестирования. Если объект состоит из нескольких микросервисов, репозиториев может быть много. Так же можно подложить что угодно еще, например описание пользовательских сценариев.
На выходе мы получаем информацию подготовленную в соответствии со стандартными шаблонами:
-Бизнес спецификация - бизнесовое описание функций + сценарии
-Техническая спецификация - архитектура сервисов и их взаимодействия
-API спецификация по каждому сервису
-Если уже есть тескейсы, то описание правильного поведения системы на основе кейсов
В итоге мы имеем довольно компактное, структурированное, и стандартизированное описание объекта тестирования.
Дальше уже остальные скиллы держат этот как контекст, для принятия решений.
Действительно, мы сейчас отлаживаемся на "простых" проектах. Но думаю задача тестирования "больших" проектов вполне себе решаемая, даже с текущем уровнем технологий. Конечно нужно будет подумать про оптимизации для экономии контекстного окна. Можно дробить задачи тестирования, можно декомпозировать объект тестирования, управлять загрузкой глобального контекста, разделять задачи на несколько субагентов (у каждого субагента свое личное окно контекста, у opus 1 000 000 токенов)
Смотря что считать за процесс. Вникать в тему использовании ИИ в тестировании я начал в октябре 2025. Это были эксперименты с разными участками QA на разных стеках, так же в процессе в голове собирались идеология и архитектура проекта. Примерно с февраля я начал уже плотно заниматься реализацией на Claude Code, через 2 недели был готов MVP описанного процесса, но после этого было еще бесчисленное количество фиксов и улучшений. Работа с анализом результатов ведется на постоянной основе.