Привет! Меня зовут Александр Чернышев, я занимаюсь тестированием мобильных приложений hh.ru, и за последние полгода моя рабочая рутина кардинально поменялась благодаря ИИ-инструментам, которые мы активно используем в HeadHunter. В моём случае это Claude Code с моделью Opus 5 — по моему опыту, она лучше всего справляется с рабочими задачами. Оговорюсь: у меня подписка Max, поэтому лимитов хватает с запасом. Сейчас я подключаю агента к большинству своих задач. Основа рабочего процесса — это скиллы: инструкции, которые задают агенту последовательность действий и не дают ему каждый раз импровизировать. Вместе с ними я использую MCP-серверы и плагины, через которые агент может взаимодействовать с внешними инструментами, например с Figma (figma-mcp).

В этой статье я разберу весь жизненный цикл задачи — от подготовки чеклиста и сверки с ТЗ до ретеста и автотестов — и покажу, как на каждом этапе использую ИИ-агента. Расскажу, какие локальные и корпоративные скиллы и MCP помогают мне в работе и что в итоге всё равно остаётся на стороне тестировщика. Сразу оговорюсь: названия скиллов у нас внутренние — за пределами hh.ru вы их не встретите. Поехали!

Шаг 1. Чеклист из кода (/generate-test-instructions)

Для начала стоит сказать, что в нашей компании давно нет разделения на ручных и авто-QA: каждый инженер работает с кодом приложения напрямую. Поэтому, когда приходит задача на тестирование, мы открываем Claude Code CLI или Desktop прямо из фиче-ветки и первым делом собираем чеклист проверок.

Для этого мы используем скилл /generate-test-instructions. По сути, это markdown-файл с инструкцией для агента: где взять базовую ветку, как получить merge-base, что прочитать целиком, в каком порядке рассуждать и что не стоит включать в результат. 

Отдельный промт не нужен: запускаем скилл, агент анализирует diff и собирает чек-лист. На выходе получаем пять фиксированных разделов: затронутые модули, что изменилось, регресс, что проверить, аналитика и конфиги. Пошаговые сценарии намеренно не используем, тестировщик знает приложение лучше модели, которая на этом этапе видит только diff. Поэтому задача агента — не расписать тестирование за человека, а показать, что изменилось и где искать потенциальные проблемы.

В результате мы получаем полноценную карту изменений, от которой можем отталкиваться и строить стратегию тестирования. Причем сейчас даже запускать скилл вручную не приходится: он автоматически вызывается на уровне CI при создании пулл-реквеста. Остаётся только открыть пулл-реквест и забрать  готовый чеклист.

Шаг 2. Сверка с ТЗ и макетами (/read-jira и figma-mcp)

На первом шаге агент собрал чек-лист только по коду. Но нам важно проверить не только саму реализацию, но и то, насколько она соответствует ТЗ и макетам. Поэтому следующим шагом просим агента актуализировать чек-лист, сопоставив его с ТЗ из задачи в Jira и макетом из Figma.

За ТЗ отвечает скилл /read-jira. Передаем ему ссылку на задачу, а дальше он через  MCP-сервер Jira получает нужные данные, в том числе ключ и описание задачи.

С макетами работает Figma MCP: он дает агенту доступ к структуре нод и скриншоту.В Figma копируем ссылку на конкретный слой через Copy link to selection — так в ней будет параметр node-id. Без него агент читает фрейм целиком и тратит лишние запросы, а нам это не надо. 

Отдаём ссылку агенту вместе с промптом. Он читает ноду, подмечает структуру: размеры, вложенные блоки, тексты и сравнивает это с кодом.

В итоге у агента есть три источника: код, ТЗ из Jira и макет из Figma. Их можно сверить между собой и ещё до ручного тестирования найти расхождения: например, баги вёрстки или отсутствующие части флоу. Это заметно сокращает время и повышает качество тестирования.

Шаг 3. Сверка iOS и Android по одной фиче (/hh-mobile-crossplatform)

Но и это ещё не всё. Наш следующий шаг — проверить, одинаково ли работает фича на Android и iOS. У нас есть доступ к коду обеих платформ, поэтому такую сверку тоже можно поручить агенту. 

Достаточно написать: «Сравни, как сделали на iOS» или «Сравни, как сделали на Android». Скилл находит реализацию одной фичи в iOS- и Android-репозиториях и ищет расхождения по 14 осям: бизнес-логика, состояния экрана, крайние случаи, аналитика, эксперименты, API, кэш, сетевые ошибки, авторизация, оффлайн, конфигурация, навигация, тексты, тесты. 

На выходе получаем саммари с найденными различиями между платформами. Такая сверка помогает заметить то, что могли упустить при декомпозиции фичи: например, на одной платформе обработали граничный случай, а на другой — нет. QA и разработчики сразу видят такие расхождения и могут понять, какие из них ожидаемы, а какие требуют проверки.

Шаг 4. Ручное тестирование и симулятор в Claude Code

Теперь можно заняться работой, ради которой всё это затевалось. Часть этой работы тоже можно отдать агенту: в июле 2026 года в Claude Code Desktop встроили iOS Simulator — пока в публичной бете, только на macOS. Агент может собрать iOS-приложение, установить его, запустить, прокликать созданный ранее чек-лист и проверить результат. Для этого достаточно команды вроде: «Собери и запусти приложение, проверь его по чек-листу».

Не могу сказать, что я сильно доволен симулятором. По скорости здесь пока выигрывает человек: тестовые сценарии я прохожу в 10–30 раз быстрее агента. Кроме того агент может тупить на ровном месте и уходить далеко в степь и заодно быстро съедать лимиты. 

Вдобавок есть важное «но». Только человек способен оценить UX: здесь важен не формальный результат проверки, а опыт использования приложения. Насколько понятен сценарий, удобно ли взаимодействовать с интерфейсом, где пользователь может запутаться — такие вещи лучше замечаешь, когда сам проходишь флоу.

И не стоит забывать, что агент работает только в симуляторе, а тестировать нужно на реальном устройстве. Симулятор запускает приложение на процессоре Mac с его памятью и скоростью, поэтому такое тестирование не воспроизводит реальные условия работы смартфона и может не показать проблемы с производительностью, долгую холодную загрузку и краши на бюджетных телефонах. Отличается и само взаимодействие с интерфейсом: вместо тач-события в симуляторе — мышь, поэтому жесты, скорость свайпа и попадание пальцем в маленькие элементы ощущаются иначе. Значительная часть багов, которые доходят до пользователей, живёт именно в этих зонах. 

Поэтому я использую симулятор как дополнительный инструмент: отдаю агенту часть функциональных проверок и прогон чек-листа, а сам параллельно занимаюсь тем, где важны реальное устройство и человеческая оценка. Финальную приёмку фичи в любом случае провожу на реальном девайсе.

Шаг 5. Тестирование аналитики (/test-analytics)

После функциональных проверок переходим к мобильной аналитике. Это одна из самых трудоёмких частей тестирования: проходишь сценарий, ищешь нужное событие среди сотен строк и сверяешь параметры. Что-то легко пропустить, а ошибка в трекинге может привести к тому, что после запуска фичи мы не сможем корректно оценить её эффект на пользователей.

(Кстати, недавно мой коллега рассказывал о нашей мобильной аналитике на митапе— запись можно посмотреть на Youtube или VK-Video). 

Чтобы не сверять всё вручную, я использую скилл /test-analytics. Прежде надо сказать, что в hh есть единый репозиторий hh-mobile-analytics: в нём в формате YAML описаны все события, отправляемые из мобильных приложений (iOS и Android). Этот репозиторий служит единственным источником правды для обеих платформ. Это значит, что скилл на входе принимает пулл-реквест в develop с новой аналитикой в соответствующий репозиторий. 

Перед запуском мы вручную проходим флоу приложения, и вместе с пулл-реквестом передаём  файл с затреканной аналитикой. Это может быть logcat файл или экспорт из Charles (.chls).

Дальше скилл сопоставляет три источника: пулл-реквест аналитики, код приложения и затреканые события. Первый показывает, что должно трекаться, второй — что реализовано в коде, третий — что произошло на самом деле. Так можно увидеть, где именно возникло расхождение. 

На выходе получаем диагноз в виде markdown-отчета с таблицей по всем событиям и разбором каждой проблемы: цитата схемы → что было затрекано/что не было затрекано → причина.

Скилл сильно ускоряет тестирование аналитики и сводит к минимуму человеческий фактор. То есть избавляет нас от долгой, тяжелой и скрупулёзной работы, чему я лично несказанно рад.

Шаг 6. Быстрый баг-репорт (/bug-report)

Баг нашли — теперь его нужно передать разработчику. Со скиллом создание баг-репорта по шаблону через jira-mcp занимает меньше трёх минут и избавляет от рутины с оформлением тикета по структуре  «идеального баг-репорта». 

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

Часть контекста он добирает сам. Платформу определяет по репозиторию, а если баг найден в текущей ветке, подтягивает её имя, номер задачи и затронутые файлы. Там, где есть ограниченный набор вариантов — например, исполнитель или тип связи, — агент предлагает выбрать нужный вариант кликом вместо набора строки.

В итоге вместо того, чтобы открывать вкладку в Jira, вручную писать подробный баг-репорт, добавлять связи и префиксы в название тикета, достаточно перейти в ветку в папке проекта, накидать описание бага и приложить скрин. Скилл через наш внутренний Jira MCP сам проставит связи, по шаблону опишет шаги и предусловия, спросит исполнителя через AskUserQuestion и покажет черновик на одобрение. Останется только всё проверить и подтвердить — и тот самый «идеальный баг-репорт» появится в Jira на радость разработчику.

Шаг 7. Ретест (/retest)

После того как разработчик починил баги, нужно провести ретест. Но  ещё лучше перед этим сделать статический анализ кода. Для этого есть скилл /retest. 

Он читает тикет с баг-репортом, разбирает дифф и по каждому дефекту даёт вердикт в виде таблицы. Так можно заранее понять, какие изменения внес  разработчик и действительно ли они должны исправить найденную проблему.

Шаг 8. Автотесты (/ui-test)

Когда фича протестирована и вмержена в develop, самое время приступить к автотестам. В hh мы используем нативные фреймворки Kaspresso (о нём рассказывали здесь) и Rafinad (о нём можно прочитать здесь). Дальше речь пойдёт конкретно про UI-тесты на iOS, поскольку к созданию скилла я имею непосредственное отношение.

В iOS-приложениях hh своя развитая инфраструктура UI-тестов: DSL-разметка Accessibility, типизированные Page Object и сервисы фикстур, привязанные к Swagger. Всё это подробно описано в стайл-гайде — md-файле в самом репозитории.

Скилл /ui-test состоит из папки с SKILL.md и девяти файлов в references/. Точка входа не содержит правил, она маршрутизирует, а сами правила лежат отдельно.

Чтобы запустить скилл, достаточно кратко описать желаемый тест, например: «Напиши автотест на отклик через экран вакансии пользователем, зарегистрированным в Беларуси». Чем больше деталей, тем лучше, но обычно хватает минимума по правилу: что делаем, где проверяем и как.

Результат складывается из трёх частей: Accessibility-файл, Page Object и тест.

• Accessibility-файл лежит рядом с модулем, а не в тестах. Без него DSL не знает, к какому классу привязывать якоря, по которым ищется элемент на экране.

• Page Object строится по жёсткой структуре: Waits, Actions, Asserts, Private. Здесь есть ещё два правила: не писать методы «на будущее»  — метод без вызова в тесте не верифицирован — и не дублировать уже созданные универсальные PO из shared модуля.

• Тест. Имя состоит из трёх обязательных частей: test_<СтартовыеУсловия>_<ЧтоДелаем>_<ЧтоПроверяем>. И главное правило скилла: тест заканчивается assert*(), а не действием или ожиданием.

Как это выглядит на практике

Допустим, есть простая задача: «Напиши тест на то, что при пустом списке откликов со статусом „Отказ“ показывается заглушка». Вот что происходит дальше.

1. Разведка — где вообще этот экран

Агент не начинает сразу писать код. Сначала он ищет экран в коде и убеждается, что нашёл именно тот, — по текстам и по описанию интерфейса. 

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

К концу этого шага агент должен назвать цепочку целиком и для каждого её звена определить, есть ли уже описание нужного экрана в тестах или его придётся писать. Отдельно он ищет похожие тесты. Если такие уже есть, подготовку данных можно взять оттуда, а не изобретать заново.

2. Сверка — что уже написано

Теперь агент смотрит, что из необходимого уже существует: описание целевого и родительского экрана, и способ перехода между ними. 

Универсальные компоненты — диалоги, списки выбора, подсказки — у нас описаны один раз на всех, поэтому скилл прямо велит сначала заглянуть туда и не плодить дубли. 

На этом же этапе могут всплыть пробелы. Например, на родительском экране нет метода для перехода, а нужная кнопка не размечена. Лучше узнать это сейчас, чем после написания теста.

3. Разметка экрана

Если целевой экран не размечен, агент начинает с него. Он описывает структуру экрана: какие есть блоки, какие элементы внутри и что из них повторяется списком. Потом расставляет пометки на самих элементах в интерфейсе. 

Скилл держит агента за руку в двух местах. Во-первых, имена элементов берутся из кода, а не придумываются «по смыслу для пользователя». Во-вторых, размечается только то, что нужно для текущего теста. Никакого «заодно помечу всё, вдруг пригодится».

4. Описание экрана для тестов

Дальше агент пишет объект, через который тест будет работать с экраном. Напрямую к элементам тест не обращается — только через такое описание. 

Внутри всё раскладывается по трём группам в фиксированном порядке: ожидания, действия, проверки. Действия называются потому, что физически делает пользователь: нажал, выбрал, ввёл.

5. Сам тест

Теперь можно собирать сам тест. Это цепочка вызовов, которая читается как обычный сценарий: дождались главный экран, открыли отклики, выбрали вкладку «Отказ», дождались заглушку, проверили её заголовок. 

6. Тестовые данные

Этот шаг может не понадобиться вовсе, и скилл этому только рад.. Если данные всё-таки нужны, агент сначала читает кодовую базу целевого экрана — не ради интерфейса, а ради предусловий. Например, экран может требовать подтверждённый телефон, активное резюме. Из интерфейса это не видно, поэтому без нужных данных тест падает в неожиданном месте и с невнятной причиной. 

После этого агент готовит только те данные, которые действительно нужны тесту, и задаёт им уникальные названия, чтобы параллельные тесты не цеплялись друг за друга.

7. Самопроверка

В конце агент прогоняет свою работу по чек-листу из двадцати пунктов — тому самому, по которому результат потом будут проверять на ревью.

Заключение

Работа QA меняется. Тестировщик всё меньше просто выполняет готовые процедуры и всё чаще создаёт их сам. Каждый скилл в этой статье — это опыт команды, переведённый в инструкцию: что читать, в каком порядке думать и чего не делать. Раньше такой опыт передавался устно и терялся с уходом людей, а теперь он лежит в репозитории, версионируется и выполняется одинаково хоть в первый, хоть в сотый раз. Хороший скилл, по сути, — хорошо написанное ТЗ для самого себя, и умение его написать становится ключевым навыком QA-инженера.

Есть и практический вывод: агенту нужно доверять, но проверять его. Результат /test-analytics — это диагноз, а не приговор, где вердикт /retest — это повод открыть дифф, а не закрыть тикет.

Полгода назад мой день состоял из десятка мелких переключений и типовых рутинных задач. В совокупности они съедали до половины моего рабочего времени и часто сбивали мой фокус. Сегодня большую часть из этого делает цепочка скиллов, а я занимаюсь тем, ради чего вообще пришёл в тестирование: думаю, как «сломать» фичу, и смотреть на продукт глазами пользователя. 

Искусственный интеллект здесь в первую очередь лишь инструмент, который помогает делать работу быстрее. Но финальное решение и ответственность всё равно остаются за QA.

А как вы в компании используете агентов? Пишите в комментариях, будет интересно почитать!