Привет, Хабр! Меня зовут Илья Баранов, я лид тестирования в Сбер Диск. Я уже много лет занимаюсь автоматизацией тестирования и прошёл долгий путь от кликеров до современных мультиагентных систем.
Давайте проследим эту эволюцию. Сразу подчеркну: материал в статье буду подавать не хронологически, а в том порядке, как те или иные технологии и продукты попадали ко мне и были мной освоены. Возможно, часть их вы перескочили сразу, но сейчас я хочу рассказать про свой опыт, а не просто сделать сводку инструментов автоматизации.
И именно поэтому я не буду углубляться в технические аспекты той или иной системы, а расскажу в первую очередь, какие проблемы и задачи я решал с помощью этих технологий.
Эпоха кликеров
Вспомним начало. Selenium IDE, AutoIt, разные макро‑рекордеры. Принцип прост: записал действие — воспроизвёл. Наверное, большинство автоматизаторов игралось с этими «игрушками». Помню свой непередаваемый восторг, когда, установив впервые Selenium IDE, я смог записать сценарий и потом воспроизвёл его. Я же теперь настоящий автоматизатор, теперь я всё могу, пора просить повышение зарплаты. Да, тогда я был наивен и не понимал, что не стал автоматизатором, а только прикоснулся к технологиям автоматизации. При этом задача передо мной стояла довольно серьёзная.
Тогда мы разрабатывали импортозамещение для проекта БДПН — единой базы, в которой хранятся все данные об абонентских номерах телефонов в России. К этой БД обращаются операторы мобильных сетей при обработке заявок на перенос номеров, выделение пула номеров определённым операторам, высвобождение номеров после использования и так далее. В общем, сценариев много и система очень ответственная.
Мы тогда только приступили к работе, и вдруг нам сообщили радостную новость: к нам едет ревизор замминистра Россвязи. Ему очень хотелось посмотреть, что у нас есть, а мы вдруг поняли, что нам особо и нечего показать. Ну, вот требования, вот код бэка, вот страница авторизации и первая стартовая страница, и то не вся. Что показывать? И нашему владельцу продукта пришла гениальная идея: «А давайте покажем автоматизацию фронта. Ну вот, чтобы автотесты сами по страницам бегали и всё вводили. Красиво же, сделаешь же?» А я на тот момент даже ни разу не трогал автоматизацию интерфейса и вообще совсем недавно перешёл из сферы айтишного железа. Хммм, ну, надо так надо. Сделаю. И после работы я засел за разбор, как это вообще делается. Проштудировав множество статей, я понял, что максимально удобно и быстро будет сделать автоматизацию через кликер. Ещё пара вечеров, чтобы освоить всё на уверенном уровне, и вот вскоре все наши сценарии фронта были покрыты автотестами. Защитились мы отлично, получили свои торжественные рукопожатия и похлопывания по спине и продолжили развитие проекта.
Но вскоре я понял, что кликеры хороши в MVP и быстрых стартах, но для долгоиграющего проекта их не хватает. Фронт рос, тестовые сценарии постоянно менялись. При этом поддерживать их было невозможно, а можно было только сносить и переписывать заново. Нужно было искать новый инструмент автоматизации
Эпоха Selenium WebDriver (первый серьёзный скачок)
Для дальнейшей автоматизации я выбрал Selenium и Python — самую, наверное, популярную на тот момент связку языка и технологии. Попробовал перенести сценарии и понял, что легче всё переписать. Ну, а дальше понеслось погружение в стек с одновременным обучением. Написал 50 сценариев, получил простыню, освоил Page Object. Написал 200 сценариев, понял, что они повторяются, освоил параметризацию. Тесты стали проходить больше двух часов — внедряем многопоточность. Иногда осваивал новые приёмы и методы так быстро, что в пятницу, смотря на то, что написал в понедельник, думал про себя: «какой же профан это написал», и сразу переделывал всё с новой архитектурой. В какой‑то момент, покрыв уже большинство проекта новыми сценариями, словил эйфорию. Казалось, что через Selenium можно автоматизировать всё. Ради интереса начал писать скрипты для автоматизации браузерных игр и создавать различные боты. Тогда это ещё не было так распространено, и было действительно круто погружаться в эту тему.
Но через некоторое время понял, что за свободу нужно платить. Selenium хорош тем, что вам даётся, по сути, двигатель, колёса и набор запчастей, но какая машина получится, зависит только от вас. При этом часть деталей изначально приходит с браком или несовместимостью, но вы об этом узнаете только когда машина поедет (или не поедет). Постоянные флапающие тесты, нестабильность прогонов на серверах, несовместимость новых сборок Chrome с ядрами Selenium и так далее. Зачастую на поддержку уходило больше времени, чем на развитие. Но к этому моменту проект прошёл уже период бурного роста, и вся система работала довольно стабильно. Автоматизация под 90+% регресса позволяла изучать новые технологии и делала жизнь довольно комфортной.
Эпоха фреймворков (Playwright и Cypress)
Постепенно проект дошёл до готовности и перешёл в статус поддержания. Стало скучно, и тут очень вовремя меня схантил один бигтех. Новый проект — ERP‑система, которая работала на три страны (Англия, Франция, Израиль). Начал по привычке автоматизацию на связке Selenium и Python. Но через некоторое время пришла команда, с которой мы поддерживаем интеграцию, и предложила писать на Cypress и JS. У них уже был развёрнут фреймворк, написана часть автотестов, и они считали, что один стек на две наши команды будет эффективнее. Ну что же, садимся осваивать язык и фреймворк. На удивление, освоение прошло довольно быстро, хотя мне многие JS‑ники говорили, что по моему почерку видно, что я питонист. Ну а Cypress меня сразу поразил и пленил своей простотой в освоении. Буквально несколько команд — и фреймворк развёрнут. Никаких плясок с ядром браузера и интеграции его с Selenium. Буквально сел и поехал, при этом поехал быстро и с ветерком.
Да, были, конечно, проблемы. На тот момент многопоточка и дашборды с отчётами были платными функциями. Полечилось это всё самописным дашбордом и самописной многопоточкой с разметкой потоков. Неудобно, но зато даже лучше стал понимать, как всё работает под капотом.
В целом, автоматизация у меня проходила в три этапа. На первом этапе регресс сократился с недели до трёх дней. В первую очередь я автоматизировал не самые сложные и важные сценарии, а самые долгие по длительности прохождения. Это нужно было для того, чтобы команда привыкла к автоматизации и научилась доверять сценариям.
На втором этапе выбирали основные сценарии, сокращали длительность регресса до трёх часов. Пока работали в три потока, привыкали к многопоточке и быстрым регрессам.
Ну и третий этап — регресс за 40 минут. Множество потоков, максимальная стабильность системы и минимум флапов. К этому моменту сценариев было уже больше 2 тысяч.
Самое приятное во фреймворках — это быстрое погружение «ручников» и переход их в автоматизаторы. Первые самые сложные шаги с установкой и настройкой виртуальных окружений проходят очень быстро и просто, а дальше написание сценариев идёт по принципу: «посмотри архитектуру, что я создал, и повторяй за мной». За пару часов удавалось объяснить структуру проекта, за два дня ручник начинал писать свои сценарии под наблюдением, а через две недели у меня получался полностью самодостаточный стабильный автоматизатор.
Но есть и обратная сторона медали. В какой‑то момент появилось ощущение, что ты не программист, а оператор фреймворка. Настроив инфраструктуру и все технические обвязки, я перестал их трогать, и так стабильно работает же. А бесконечное написание сценариев было похоже на работу робота. Я начал понимать, что теряю навыки программиста и просто закрываю бизнес‑потребности и фичи.
Через некоторое время, когда мой проект уже стабильно прогонялся в авторежиме, меня попросили автоматизировать проект соседней команды и подготовить им автотестера на замену. Но стек, который они хотели, — это Playwright и TS. Ну что же, нужно так нужно. Осваиваю TS, после JS ничего сложного нет, и перехожу к Playwright. По ощущениям стало больше свободы по сравнению с Cypress, и удобство намного повысилось. Но оно и понятно, ведь Playwright написан на TypeScript и интуитивно интегрирован с ним. Я автоматизировал проект раньше срока, подготовил смену и заскучал. Всё работает, автотесты крутятся, баги мутятся. Но слишком всё стабильно. Ещё и санкции отрубили от нас Европу, совсем грустно стало. Пора искать новые точки роста
Эра ИИ. Уровень 1 — промптинг (мы изобрели кликер)
Пока я осваивал фреймворки и автоматизировал проекты, мир не стоял на месте. Появились ИИ‑чаты и стал активно развиваться промптинг. Помню это первое время, когда никто не понимал, как с ними жить и хорошо это или плохо. Все стеснялись говорить, что пользуются чатами для уточнений, ведь это ставило под вопрос сеньорность. Ты что‑то спрашиваешь в ChatGPT? Ты что, сам не знаешь? Сейчас это, конечно, смешно звучит.
Но, как бы то ни было, прогресс не стоял на месте, и промпт‑инженерия постепенно входила в рабочую жизнь. Как‑то серьёзно применять её на работе не получалось: закрытой агентной сети не было, а скидывать даже обезличенные журналы для разбора в общую сеть не выглядело здравой идеей. Так что для глубокого освоения новой технологии, как обычно, решил запилить свой небольшой личный проект. Чат‑бот для Telegram, подключение по API к Тинькофф и Мосбирже, вывод подборок акций и облигаций, в качестве сервера использовал одноплатник с Ubuntu. Собрать и запустить проект удалось за 6 часов субботнего вечера. При этом в качестве чатов я использовал бесплатный GPT-4 и Mistral, ничего лучшего тогда не было. Что больше всего поразило? Даже не то, что проект стабильно работает — хотя для pet‑проекта, собранного за такое время, это, конечно, тогда было удивительно, — а то, что я, продумав архитектуру, всё равно по сути не знал, как там всё работает под капотом. Я ни разу не открыл описание API ни Тинькофф, ни Мосбиржи, я не знал, какие запросы там используются, как они взаимодействуют, как обрабатываются мои запросы. Тогда я просто этому удивился, а ведь это уже были вестники новой эры — эры программирования через намерения без глубокого понимания, что происходит под капотом.
Через несколько недель я решил модернизировать свой бот, и началась жесть. Контекст не влезал в окно, между частями программы возникали швы и интеграции переставали работать. Помучавшись пару дней, я понял, что бот легче создать заново, чем переписывать по частям. На этом pet‑проект был успешно заброшен.
Оглядываясь назад, я понимаю, что чем‑то этот период напоминал эпоху кликеров. Можно было создавать личные проекты за вечер. Это давало сильный вау‑эффект, тебе казалось, что ты можешь всё. Но потом ты понимал, что больше чем pet или прототип ты ничего не выжмешь из этого подхода. При этом тогда я был уже довольно опытным инженером, многие без опыта не смогли бы и этого.
Но самое главное, что дала эта эпоха, — привыкание к ИИ в рабочем процессе. Мы стали меньше гуглить, мы стали больше спрашивать у нейронок. Мы стали доверять им. Теперь, поймав ошибку, мы не бежали на Stack Overflow, а закидывали её в чат и получали ответ, что ошибка означает и что нам нужно делать
Эра ИИ. Уровень 2 — агенты (ранний Selenium)
Постепенно в жизнь и работу стали проникать агенты. Первые — довольно нестабильные, с маленьким контекстным окном и слабыми моделями. И, познакомившись с ними, я был разочарован: работали они медленно, галлюцинировали, выдавали неверный результат. В общем, использовать их было неудобно в рамках всего проекта. Но одновременно у них появилась прекрасная опция: они могли встраиваться в проект и выполнять определённые действия. А раз агент можно встроить в часть проекта, то можно сделать цепочки из подобных узкоспециализированных агентов и существенно облегчить себе жизнь. Для меня это в первую очередь были различные агенты‑ревьюеры (своеобразная замена линтерам) и агенты по разбору упавших тестов.
В чём‑то этот период похож на эпоху раннего Selenium: инструмент уже есть, потенциальные возможности его громадны, но как использовать, чтобы всё эффективно работало, ещё никто толком не понял, и всему нужно учиться на ходу.
Из интересного, чем запомнился этот период: натравливание агента на мой личный проект из предыдущей эры. И агент справился с задачей. Оживил бот, сшил все интеграции, исправил ошибки и обновил API. В небольших проектах даже первые агенты работали прекрасно. Они получили ключевое преимущество перед промптингом: смогли увидеть весь контекст проекта и научились собирать его, не делая уродливых швов, как на теле Франкенштейна.
Эра ИИ. Уровень 3 — мультиагенты (Playwright на стероидах)
Эпоха первых агентов прошла довольно быстро. Спираль технологического развития сжалась до предела, и развитие технологий пошло галопом. Когда появились доступные агенты и мультиагентные системы, я уже работал в банке. И, признаюсь, я был не в восторге от первого опыта их использования. Но буквально за полгода всё переменилось.
Подняв свою мультиагентную систему, я не просто смог закрыть пробелы в автоматизации API, но и выстроить полноценный производственный конвейер: от сбора требований из документации аналитиков до заведения задач и создания тестовых сценариев с последующим генерированием автотестов. При этом мультиагентная система, покрытая каркасом из контекста, навыков, шаблонов, MCP‑подключений и правил, получилась максимально стабильной. Работу, на которую у меня раньше ушло бы не меньше 6–9 месяцев, я закрыл за месяц. И при этом я специально не спешил, чтобы максимально контролировать качество процесса и полученного результата.
И тут я понял, что тот самый технологический агентский прорыв, который нам долго обещали, уже произошёл. Да, сейчас я часто читаю и слышу, что мультиагентные системы что‑то не понимают, не учитывают, ошибаются. Но в том и дело, что люди тоже часто что‑то не понимают и ошибаются. Мультиагентные системы — это инструменты, которые очень серьёзно усиливают грамотных инженеров, а не заменяют их. В качестве обратной стороны медали они дарят чувство всемогущества малограмотным инженерам, и последствия их творений мы потом читаем в разгромных статьях про очередной провал внедрения агентов в продукт.
Лучше всего представлять агенты в вашем продукте в качестве сеньора, который может всё и одновременно ничего не знает о вашем продукте. Почему выбрали эту архитектуру? Почему именно этот стек? А зачем вот этот странный костыль, давайте его уберём? Все вопросы, которые задаст вам новый инженер после найма, должен задать и агент, внедрённый в ваш продукт. И только получив ответы, он сможет по‑настоящему показать себя.
У меня опять возникают аналогии с фреймворками, ведь их внедрение в автоматизацию сделало вход очень простым и быстрым. Пять команд — и фреймворк готов, десять строчек — и автотест работает. Кажется, пиши и пиши. Но без улучшения инженерных навыков всё в итоге скатится в спагетти‑код с постоянными флапами, каскадными падениями, безумными созависимостями и другими инженерными ошибками. Так что мой совет: не смотрите на агенты как на инструмент, который вывезет за вас все проблемы прямо из коробки. Рассматривайте его как вашего компаньона, который сделает вас сильнее и в разы повысит вашу эффективность
И вот мы тут...
Наверное, нужно бы написать какой‑то очень мудрый вывод. Может, даже стоило бы спросить его у одного из агентов. Но не думаю, что в этом будет какая‑то ценность, а если мудрый вывод вам всё же нужен, то можете спросить его у агентов сами. Но всё же, зачем я написал эту статью? Я хотел рассказать вам про свой инженерный опыт, не затрагивая опыт лида тестирования. Думаю, у многих он похожий, и также у многих он очень сильно расходился. Я постарался изложить всё кратко, но одновременно подробно, так, чтобы и тем, кто не погружён в технологический стек, было интересно читать и не пропустить основные главы долгого пути. Куда в итоге приведёт нас развитие ИИ, я не знаю, да и никто вам, наверное, сейчас не ответит. Слишком много переменных в этом вопросе, слишком ново, и слишком быстро развивается эта сфера. Но знаю точно, что впереди нас ждёт долгая и интересная инженерная дорога, и лучшее, что мы можем делать, это идти по этой дороге в авангарде человечества, стремясь к новым знаниям и осваивая новые технологии.
На этом всё. Пишите в комментариях, как прошла ваша трансформация, где вы сейчас, чего ждёте от грядущих ИИ‑перемен и как на всё это смотрите. С удовольствием почитаю ваши истории. Спасибо за внимание!
