Текущее поколение сеньоров должно создать поколение агентов, которым можно доверять) тогда наверное достаточно будет просто обучить пользоваться агентами
Это очень интересная тема - сейчас компаниям нет смысла нанимать джунов, тк именно джуновсую работу ИИ делает хорошо. Но откуда тогда возьмутся новые сеньоры?
Сейчас исследую вопрос оптимизации расхода токенов, и как одно из направлений - это оптимизация работы с глобальным контекстом. Уже сейчас я не скармливаю каждый раз "весь конфлюенс". В статье описано что это "выжимка" по шаблонам, всего что я считаю важным.
Но для больших проектов этого не достаточно, скармливать весь контекст для любой задачи не оптимально.
Целевой путь, но трудозатратный - это поднятие инфры для RAG/Vector search. "Выжимку" я загоняю в RAG, и в рамках каждой задачи контекст собирается только релевантный.
Временный вариант - просто сделать еще один скилл, который будет запускаться после анализа требований и выбирать релевантные данные. Например для чисто фронтовой фичи точно не нужны контракты всех микро-сервисов.
В итоге все сводиться к тому, что эффективность 1 тестировщика заметно возрастает. Не соглашусь с тезисом, что на роль оператора подойдет джун. Как раз наоборот, для того чтобы выполнять функции контроля и брать на себя управление в "сложных" кейсах, оператор должен быть "умнее" ai ассистента.
К аналитикам требования минимальные - фиксировать договоренности команды на груммингах в любом формате, следить за актуальностью требований к фиче и прорабатывать возникшие вопросы. Если этого не делать - у команды будут проблемы в любом случае. Какого то особого формата аналитике не требуется. Opus очень хорошо анализирует требования и раскладывает по шаблонам.
Блок 10 это скорей мои мечты, до которых еще далеко. Рано рекламировать.
Да, это правильный путь, если база знаний лежит в векторе это просто замечательно. Не экспериментировал с этим т.к нет ресурсов чтобы поднять стек, в рамках проекта работаю только с текстом.
Про глобальный контекст лучше мне написать отдельную статью)
Глобальный контекст - это не просто взять и "скормить" LLM-ке всю информацию которую мы нашли по проекту. Глобальный контекст нужно готовить, до недавнего времени мы делали это руками, но сейчас есть отдельный скилл который этим занимается.
На вход мы подаем как минимум - репозитории с кодом объекта тестирования. Если объект состоит из нескольких микросервисов, репозиториев может быть много. Так же можно подложить что угодно еще, например описание пользовательских сценариев.
На выходе мы получаем информацию подготовленную в соответствии со стандартными шаблонами:
-Бизнес спецификация - бизнесовое описание функций + сценарии
-Техническая спецификация - архитектура сервисов и их взаимодействия
-API спецификация по каждому сервису
-Если уже есть тескейсы, то описание правильного поведения системы на основе кейсов
В итоге мы имеем довольно компактное, структурированное, и стандартизированное описание объекта тестирования.
Дальше уже остальные скиллы держат этот как контекст, для принятия решений.
Действительно, мы сейчас отлаживаемся на "простых" проектах. Но думаю задача тестирования "больших" проектов вполне себе решаемая, даже с текущем уровнем технологий. Конечно нужно будет подумать про оптимизации для экономии контекстного окна. Можно дробить задачи тестирования, можно декомпозировать объект тестирования, управлять загрузкой глобального контекста, разделять задачи на несколько субагентов (у каждого субагента свое личное окно контекста, у opus 1 000 000 токенов)
Смотря что считать за процесс. Вникать в тему использовании ИИ в тестировании я начал в октябре 2025. Это были эксперименты с разными участками QA на разных стеках, так же в процессе в голове собирались идеология и архитектура проекта. Примерно с февраля я начал уже плотно заниматься реализацией на Claude Code, через 2 недели был готов MVP описанного процесса, но после этого было еще бесчисленное количество фиксов и улучшений. Работа с анализом результатов ведется на постоянной основе.
Текущее поколение сеньоров должно создать поколение агентов, которым можно доверять) тогда наверное достаточно будет просто обучить пользоваться агентами
Это очень интересная тема - сейчас компаниям нет смысла нанимать джунов, тк именно джуновсую работу ИИ делает хорошо. Но откуда тогда возьмутся новые сеньоры?
Сейчас исследую вопрос оптимизации расхода токенов, и как одно из направлений - это оптимизация работы с глобальным контекстом. Уже сейчас я не скармливаю каждый раз "весь конфлюенс". В статье описано что это "выжимка" по шаблонам, всего что я считаю важным.
Но для больших проектов этого не достаточно, скармливать весь контекст для любой задачи не оптимально.
Целевой путь, но трудозатратный - это поднятие инфры для RAG/Vector search. "Выжимку" я загоняю в RAG, и в рамках каждой задачи контекст собирается только релевантный.
Временный вариант - просто сделать еще один скилл, который будет запускаться после анализа требований и выбирать релевантные данные. Например для чисто фронтовой фичи точно не нужны контракты всех микро-сервисов.
Ну это не обсуждается)
Футболка огонь, будь у меня такая, вынес бы подобную фотку на превью!
Если бы я терминах Доверие назвал Надеждой, то точно не удержался бы от введения термина Любовь. И статья получилась бы про другое)
Во в части раскрыл подробнее про контекст https://habr.com/ru/articles/1020694/
В итоге все сводиться к тому, что эффективность 1 тестировщика заметно возрастает. Не соглашусь с тезисом, что на роль оператора подойдет джун. Как раз наоборот, для того чтобы выполнять функции контроля и брать на себя управление в "сложных" кейсах, оператор должен быть "умнее" ai ассистента.
А как вы используете AI инструменты для тестирования на своих проектах?
Чувствуете ли реальную пользу?
А может быть вас заставляют)?
Делитесь своим опытом\идеями в комментариях!
Интересно какими моделями был опыт? Уровень модели сильно влияет на результат. Например 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 описанного процесса, но после этого было еще бесчисленное количество фиксов и улучшений. Работа с анализом результатов ведется на постоянной основе.