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