|
|
||
Автоматизатор тестирования работает на стыке трёх миров: кода продукта, тестового кода и тест-менеджмента. Каждый из этих миров порождает собственную рутину. Аудит изменений в существующих автотестах занимает часы. Разбор упавшего билда в Allure или Jira превращается в поиск иголки в логах. Онбординг нового инженера в кодовую базу тестов растягивается на недели. Казалось бы, эта работа не требует креативности и должна быть делегирована. На практике она съедает время, которое могло бы уйти на расширение покрытия и работу с хрупкими тестами.
Opencode - открытый AI-агент для работы с кодом, доступный как терминальное приложение, десктоп и IDE-расширение. Его ключевые свойства для QA-инженера: он работает в локальном репозитории, поддерживает произвольные модели через 75+ провайдеров, умеет запускать bash-команды, читать и редактировать файлы, подключаться к внешним системам через Model Context Protocol (MCP), и его поведение настраивается через агентов, тулы и скиллы. На момент написания статьи у Opencode более 195 тысяч звезд на GitHub и около 950 контрибьюторов. Это не игрушка, а Infrastructure-as-Code для рутин QA.
Ниже - семь прикладных кейсов, которые автоматизатор тестирования может закрыть через Opencode уже сегодня. Каждый кейс сопровождается конфигурацией и кодом, который можно скопировать в проект. Я намеренно избегаю общих рассуждений про "AI повысит продуктивность". Речь идёт о конкретных операциях: читать тест-кейс из TestOps, сгенерировать по нему pytest, проверить чистоту кода теста, прогнать через pytest, проанализировать упавший результат, открыть дефект в Jira.
Главная идея всей статьи проста. Время автоматизатора - конечный ресурс, и его не следует тратить на операции, которые машина делает лучше и быстрее. Но делегирование имеет смысл только тогда, когда его результаты проверяемы. Opencode даёт такую проверяемость: каждый шаг агента виден, каждая правка дифабельна, каждая команда в bash подтверждается через permission-систему. Это и есть честная автоматизация рутины - без чёрных ящиков.
Первое, что делает новый автоматизатор в проекте - пытается понять, как устроены существующие тесты. Где лежат фикстуры, как называется базовый класс для page object, какие селекторы считаются принятыми, как работает teardown. Раньше для этого нужен был созвон с командой и несколько дней чтения чужого кода. Opencode в режиме Plan закрывает эту задачу за полчаса.
Plan - встроенный primary-агент с двумя ключевыми ограничениями: правки файлов и bash по умолчанию находятся в статусе ask, то есть требуют подтверждения. Это значит, что агент может прочитать весь репозиторий, проанализировать структуру, найти все тесты по паттерну test_*.py или *Spec.groovy, но не может ничего изменить. Для аудита это критично: результатом работы становится не "патч, который кто-то случайно применил", а текстовый отчёт, который инженер читает и принимает решение.
Запуск выглядит так. В терминале в корне репозитория автотестов открывается Opencode, клавишей Tab переключаемся в режим Plan, и в подсказке пишем: "Найди все Page Object классы, построй карту зависимостей между ними и фикстурами, выдели три самых сложных теста по числу шагов". Агент проходит по дереву, читает ключевые файлы, строит граф зависимостей, возвращает структурированный ответ. Никаких правок. Никакого риска.
Это особенно полезно при наследовании тестового проекта от другой команды или подрядчика. Вы получаете карту - что есть, где связано, что потенциально хрупко. Карта остаётся в истории сессии, её можно расшарить через /share коллегам, чтобы они получили тот же контекст без повторного аудита. Каждый новый член команды онбордингится через готовый отчёт, а не через устные рассказы в Zoom.
Бонус: у Plan можно задать температуру генерации 0.1, и ответы будут детерминированными. Два разных инженера, запустив аудит одного репозитория, получат практически идентичные карты. Это превращает "понимание кода" из субъективного впечатления в воспроизводимый артефакт. В команде из десяти QA это экономит десятки часов в месяц.
Автотесты - это код, и к нему применимы те же стандарты ревью, что к продакшену. На практике автотесты ревьюят по остаточному принципу: "зелёный - значит, пущай". Хрупкие селекторы, sleep вместо wait, дублирование фикстур, утечка состояния между тестами - всё это пропускается именно на ревью автотестов. Причина банальна: у PR-ревьюера нет времени вникать в каждый тест, а команда растёт быстрее, чем культура ревью.
Opencode решает это через собственного subagent-а с read-only доступом и явным промптом. Создаём файл ~/.config/opencode/agents/test-review.md со следующим содержимым:
--- description: Ревью автотестов на хрупкость, чистоту и соответствие конвенциям mode: subagent permission: edit: deny bash: deny webfetch: deny temperature: 0.15 --- Ты ревьюер автотестов. Анализируй только тестовый код и его инфраструктуру. Фокус: - Хрупкие селекторы (CSS по тексту, XPath с position(), абсолютные пути) - sleep вместо явных wait / expected conditions - Утечка состояния между тестами (отсутствие teardown, общие мутации) - Дублирование фикстур и page object - Тесты без assert (smoke, которые ничего не проверяют) - Тесты с побочными эффектами (запись в общую БД, отправка реальных запросов) Выводи замечания списком с указанием файла и строки. Правок не предлагай - только наблюдения.
Файл лежит в глобальной конфигурации, поэтому агент доступен во всех проектах на этой машине. После создания его можно вызвать через @test-review в любом PR-бранче: "@test-review посмотри изменения в tests/ в этом PR". Subagent поднимается, читает только diff (или указанные файлы), возвращает структурированный список проблем. Время ревьюера тратится не на поиск, а на принятие решений по найденному.
Важно, что правок агент не делает. Это соответствует золотому правилу: инструмент должен облегчать поиск проблем, но решение - за человеком. Автоматическое "исправление" хрупких селекторов в PR-ревью - это антипаттерн, потому что за каждым хрупким селектором может стоять изменение продукта, которое тест не учёл. Агент показывает проблему; инженер решает, менять селектор, менять продукт или закрыть тест как known issue.
На практике в команде из пяти автоматизаторов такой агент за неделю вскрывает 30-50 проблем, которые иначе дожили бы до production-инцидента. Это не "AI заменяет ревьюера" - это "AI делает ревьюера ревьюером, а не гуглодокументом". И это ровно та экономия человеческого внимания, ради которой и стоит автоматизировать.
Тест-менеджмент - отдельный мир, в который автоматизатор ходит через браузер. Allure TestOps, Jira, Bitbucket - у каждого свой UI, своя авторизация, свой способ экспорта. Большую часть времени в этих системах инженер делает три вещи: читает тест-кейсы, заводит дефекты по упавшим тестам, ищет PR, в котором изменился тестируемый код. Каждое из этих действий можно выполнить из Opencode через MCP.
MCP - открытый протокол Anthropic, который позволяет языковым моделям вызывать внешние инструменты. Opencode поддерживает как локальные MCP-серверы (процессы на вашей машине), так и удалённые (HTTP-эндпоинты с OAuth). Подключение описывается в opencode.json в корне проекта. Например, чтобы дать агенту доступ к Allure TestOps, Bitbucket и Jira, достаточно такого блока:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"allure": {
"type": "remote",
"url": "https://allure.testops.example.com/mcp",
"headers": { "Authorization": "Bearer {env:ALLURE_TOKEN}" }
},
"bitbucket": {
"type": "local",
"command": ["bun", "x", "bitbucket-mcp-server"],
"environment": {
"BITBUCKET_HOST": "https://stash.example.com",
"BITBUCKET_TOKEN": "{env:BB_TOKEN}"
}
},
"jira": {
"type": "remote",
"url": "https://jira.example.com/mcp",
"oauth": {}
}
}
}
После этого агенту можно сказать: "Найди в Allure тест-кейс по сценарию "Оплата картой через YooKassa", прочитай его шаги, найди в Bitbucket PR, где менялся эндпоинт /payments, и проверь, покрыт ли он тестом". Opencode сам решит, какие тулы вызвать, в каком порядке, как склеить результаты. Для инженера это выглядит как вопрос на естественном языке; под капотом - цепочка из 5-8 вызовов разных MCP.
Есть важная оговорка про контекст. Каждый MCP-сервер добавляет в промпт описание своих тулов, и они съедают токены. Сервер GitHub MCP известен тем, что один добавляет 5-10 тысяч токенов. Поэтому в Opencode принято подключать только те MCP, что реально нужны в проекте, и отключать их через enabled: false или через permission-паттерны "jira*": "ask". Это не косметика - это ограничение контекстного окна, которое напрямую влияет на стоимость и качество работы агента.
Экономический эффект от MCP-интеграции измеряется просто. Раньше для триажа одного упавшего теста инженер открывал три вкладки, искал ID кейса, копировал шаги, искал коммит, вставлял ссылки. Сейчас это одна фраза в Opencode. Если у вас 20 упавших тестов в день и на каждый уходило 7 минут ручной работы - это 2.3 часа в день, которые возвращаются в инженеру. В месяц - около 50 часов, то есть почти треть FTE. Это и есть конкретика, а не "AI повысит продуктивность на 30%".
Opencode умеет не только вызывать чужие тулы, но и позволяет писать собственные. Это закрывает один из самых болезненных кейсов автоматизатора: генерацию тестового кода из тест-кейсов, описанных в TestOps. Сценарий классический - в Allure лежит 300 кейсов по новому функционалу, их надо превратить в pytest-файлы. Раньше это была копипаста с переименованием. Теперь это один тул, который по ID кейса возвращает готовый черновик теста.
Custom тулы в Opencode определяются как TypeScript-файлы в .opencode/tools/ проекта или в ~/.config/opencode/tools/ глобально. Имя файла становится именем тулы. Внутри тулы можно вызывать любой внешний код - Python, bash, curl - через Bun-шелл. Вот рабочий пример тулы, которая по ID тест-кейса в Allure генерирует pytest-черновик:
import { tool } from "@opencode-ai/plugin"
import path from "path"
export default tool({
description: "Сгенерировать pytest-черновик из тест-кейса Allure",
args: {
testCaseId: tool.schema.number().describe("ID тест-кейса в Allure"),
module: tool.schema.string().describe("Имя модуля для файла (например, checkout)")
},
async execute(args, context) {
const script = path.join(context.worktree, ".opencode/tools/gen_test.py")
const result = await Bun.$`python3 ${script} ${args.testCaseId} ${args.module}`.text()
return result.trim()
}
})
Сам gen_test.py читает тест-кейс из Allure API, нормализует шаги, генерирует функции test_* с маркерами pytest и сохраняет файл в tests/<module>/test_<slug>.py. Возвращаемый тулой текст попадает в контекст агента, и дальше Opencode сам решает: дописать фикстуры, проверить импорты, запустить тест на синтаксис.
Ключевой момент - тулы не заменяют инженера, а снимают с него "механическую" часть. Генерация черновика из 30 шагов кейса занимает секунды. Доработка - минуты. Раньше это была операция на 20-30 минут на кейс. По 300 кейсам это 100-150 часов работы, которые возвращаются в работу с хрупкими тестами и edge-кейсами. Это и есть смысл автоматизации: не "заменить человека", а "убрать у него работу, в которой он не нужен".
Важно соблюдать границы тулы. Тула должна делать одну вещь и хорошо. Если она пытается и кейс читать, и тест генерировать, и тест сразу прогонять - она становится непредсказуемой. Принцип единственной ответственности здесь работает ровно так же, как в продакшен-коде. Лучше три тулы: allure_get_testcase, gen_pytest_skeleton, pytest_run. Их можно компоновать в промпте: "Возьми кейс 1234, сгенерируй скелет, прогоняй, поправь импорты, если упало".
У каждой зрелой команды QA есть негласные правила. Селекторы только через data-testid, никаких absolute XPath. Ждём элемент через expect(locator).to_be_visible(), не через time.sleep(2). Один тест - один assert по основной сценарию, остальные - soft. Эти правила живут в Notion, в голове у лида, в комментариях к PR. У нового инженера уходит месяц, чтобы их выучить.
Opencode предлагает механизм Skills - переиспользуемые инструкции, которые агент подгружает по требованию. Скилл описывается файлом SKILL.md в папке .opencode/skills/<name>/ проекта или глобально в ~/.config/opencode/skills/. В YAML-фронmatter - имя, описание, опционально license и compatibility. Ниже - тело с правилами в свободной форме.
--- name: qa-conventions description: Конвенции команды по автотестам на pytest + Playwright. Используй при написании и ревью тестов. --- ## Селекторы - Только data-testid. CSS по тексту и XPath по позиции запрещены. - Если data-testid нет - поднимай тикет, не пиши хрупкий селектор. ## Ожидания - Используй expect(locator).to_be_visible() и to_have_text(). - time.sleep() запрещён. Если без него никак - выноси в фикстуру и комментируй причину. ## Структура теста - Один тест = одна пользовательская сценария. - Один основной assert + не более двух soft assert на смежные состояния. - Precondition выноси в фикстуру, не дублируй в каждом тесте. ## Именование - test__ _ (...) - Папки: tests/ /test_*.py
Когда этот скилл лежит в репозитории, любой агент Opencode в проекте видит его через available_skills и может подгрузить через тулу skill. В промпте можно явно написать "используй скилл qa-conventions", или агент сам догадается по описанию. После загрузки все правила скилла действуют до конца сессии - агент не предложит time.sleep, не сгенерирует XPath с position(), не напишет тест с пятью assert на разные сценарии.
Это решает сразу две проблемы. Первая - онбординг. Новый инженер в первый день получает не "прочитай Confluence", а рабочую среду, где агент уже знает правила команды. Он учится не из документа, а из примеров, которые генерирует агент в соответствии с правилами. Вторая - дрейф конвенций. Правила в Notion устаревают за полгода, потому что никто не ходит их перечитывать. Скилл в репозитории меняется через PR, как любой код. Правила версионны и проверяемы.
Можно пойти дальше и завести отдельный скилл под каждый фреймворк: qa-pytest, qa-playwright, qa-junit5. Они не конфликтуют - Opencode подгрузит нужный по описанию в промпте. В команде, где параллельно идут UI-тесты на Playwright и контрактные на pytest, это снимает путаницу в правилах.
Упавший билд автотестов - это всегда смесь трёх типов проблем. Real failure - что-то сломалось в продукте. Flaky - тест упал из-за тайминга, окружения, гонки. New bug - раньше проходило, теперь падает, и это сигнал. Без триажа всё сваливается в одну кучу "красное", и инженер тратит час на разбор, что из этого требует тикета, а что - рерана.
Opencode закрывает триаж через связку bash + MCP. Сначала агент получает список упавших результатов через Allure MCP (allure_list_test_results с фильтром status in ["failed","broken"]). Для каждого результата он идёт в историю через allure_get_test_result_history и смотрит, как часто тест падал за последние 20 запусков. Если падает больше чем в 30% случаев, но не всегда - это flaky. Если падает первый раз после долгого зелёного - это кандидат на новый баг.
Дальше агент идёт в код теста через тулу read, читает последние изменения через git log -p tests/... через bash, и формирует гипотезу. Промпт выглядит так: "Найди в Allure упавшие тесты за последний запуск, классифицируй на real / flaky / new bug, для real - почитай код теста и код продукта в районе падения, предложи гипотезу причины". На выходе - табличка: тест, тип, гипотеза, ссылка на код, рекомендация (тикет / реран / рефакторинг).
Особенно ценна классификация flaky. В большом проекте 5-10% тестов - flaky по своей природе (асинхронные операции, разделяемое состояние, мокирование времени). Без явного анализа они маскируют реальные баги: "у нас опять 20 красных, ну, это наши flaky, перезапустим". Когда Opencode явно показывает "эти 18 - flaky по паттерну, эти 2 - новые падения, вот их и смотрите" - фокус команды смещается на то, что действительно важно.
Здесь работает та же логика, что и с code review. Инструмент не принимает решение за инженера. Он делает невидимую работу видимой. Реальный дефект vs flaky - это разные действия: одно ведёт в Jira, другое - в рефакторинг теста. Без классификации и то, и другое утопает в шуме. С классификацией - каждое получает свой workflow. И время автоматизатора тратится на решение, а не на сортировку.
Запуск тестов из агента - страшная для многих вещей операция. Вдруг агент решит не pytest tests/, а pytest --clean-cache --delete-all? Или, что хуже, git reset --hard в процессе разбора? Opencode решает это через granular permissions, и для bash-команд это работает особенно тонко.
Permission-система позволяет задать белый список разрешённых команд и паттернов. Например, для агента, который только запускает тесты и читает вывод, конфигурация выглядит так:
{
"agent": {
"qa-runner": {
"description": "Запуск автотестов и разбор вывода",
"mode": "primary",
"permission": {
"edit": "ask",
"bash": {
"*": "deny",
"pytest *": "allow",
"python -m pytest *": "allow",
"poetry run pytest *": "allow",
"allure serve *": "ask",
"git log*": "allow",
"git diff*": "allow",
"git status*": "allow"
}
}
}
}
}
Здесь * запрещает всё, и затем конкретные паттерны открывают только нужное. Правило "последнее совпадение побеждает" означает, что pytest tests/ разрешён, а rm -rf tests/ - нет. git push - нет. allure serve требует подтверждения, потому что поднимает локальный сервер и может затратить порт.
С таким агентом можно смело делегировать цикл "запустил тест - упало - прочитал лог - пофиксил импорт - перезапустил - прошло". Каждое действие в bash проходит через permission-фильтр. Если агент хочет сделать что-то за пределами белого списка - он либо просит подтверждения, либо останавливается. Это и есть та самая проверяемая автоматизация: не "агент делает, что хочет", а "агент делает, что ему разрешено, в рамках, заданных человеком".
На практике это работает в том числе для локальной отладки. Готовишь PR с новым тестом, запускаешь через агента pytest tests/checkout/test_payment.py -k test_yookassa_card. Если падает - агент читает traceback, ищет проблему в коде теста, предлагает правку (которую ты подтверждаешь), перезапускает. Цикл от 5 минут до 30 секунд. За час так можно прогнать 15-20 итераций отладки нового теста, что раньше занимало полдня.
Бонус для команды: агента с таким permission-профилем можно не бояться дать джуну. Джон не сломает репозиторий, не запушит в main, не удалит кэш. При этом он учится работать с агентом в реальных задачах, а не на учебных стендов. Это серьёзно снижает порог входа в автоматизацию для новичков и разгружает лидов от постоянных "а можно я запущу".
Все семь кейсов объединяет одно: они не заменяют автоматизатора, они освобождают его от рутины. Аудит кодовой базы без прав записи - это час работы вместо дня. Code review через собственного агента - это 30-50 вскрытых проблем в неделю, которые иначе дожили бы до production. Allure и Jira через MCP - это 50 часов в месяц, которые возвращаются инженеру из браузерных вкладок. Генерация тестов из кейсов - это 100-150 часов на релиз, которые раньше уходили в копипасту. Skill с конвенциями - это онбординг за неделю вместо месяца. Триаж flaky - это фокус на реальных багах вместо шума. Запуск тестов с permissions - это безопасная делегировка для джунов и ускорение отладки для всех.
Золотое правило, о котором стоит помнить при внедрении всего этого: каждый шаг агента должен быть проверяем. Opencode даёт инструменты для этого - permission-система, read-only режим Plan, дифы для правок, история сессий через /share. Если вы используете Opencode как чёрный ящик, который "сам что-то делает" - вы получаете ровно те риски, которых боятся скептики AI. Если вы используете его как инструмент с явными границами - вы получаете автоматизацию, которую можно доверять.
Главная идея дискурса, который проходит через все эти кейсы: время автоматизатора - конечный ресурс. Каждый час, потраченный на копипасту из TestOps, на разбор шума в упавших тестах, на объяснение новому инженеру, почему именно так пишется фикстура - это час, не потраченный на то, в чём человек незаменим. На работу с edge-кейсами, на анализ корневых причин, на проектирование тестовой стратегии. Инструмент должен забирать механическое, чтобы у человека оставалось умственное.
И последнее. Opencode - открытый софт, и это не маркетинговая фраза, а критическое свойство. Вы можете прочитать исходный код тулы, которая ходит в ваш Allure. Вы можете изменить промпт агента, который ревьюит ваши тесты. Вы можете отключить любую интеграцию одним флагом. В мире, где AI-агенты всё чаще продаются как SaaS с закрытой логикой и чужими серверами, OpenSource-агент - это форма сохранения суверенитета над собственным процессом. Вы делегируете рутину, но не контроль. Это и есть честная автоматизация.
|