Привет! Меня зовут Александр Чернышев, я занимаюсь тестированием мобильных приложений 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.
А как вы в компании используете агентов? Пишите в комментариях, будет интересно почитать!
Автор: adcher
