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

Раньше я делал это всё вручную. После того как я начал использовать ИИ как вспомогательный инструмент, рутинные задачи вроде поиска информации в материалах, сравнения условий и самостоятельного формулирования ответов стали занимать гораздо меньше времени.

Сейчас я экономлю, в среднем, 2–3 часа в день. Для мобильного банкира это много (плотность встреч большая) — посередине рабочего дня я могу заземлиться и просто погулять в парке с чашкой кофе.

Если ваша голова тоже пухнет от ежедневного информационного штурма, и вам нужен хотя бы (не)лишний час в день — этот материал для вас

Где ИИ мне действительно помогает: четыре самых частых кейса

1. Подготовке черновиков ответов клиентам

В работе мобильного банкира регулярно встречаются похожие вопросы клиентов, но каждая ситуация требует индивидуального подхода. Один из самых частых запросов — помощь в выборе подходящего тарифа и дополнительных сервисов.

Однажды ко мне обратился клиент с ресторанным бизнесом. Я описал ИИ особенности его деятельности и рассказал, какие задачи клиент хочет решить. Поскольку раньше мы уже подробно разбирали действующие тарифы и их особенности, ИИ на основе контекста нашего диалога предложил готовый черновик ответа: какой расчетный счет подойдет, какой именно эквайринг лучше взять под ресторанные реалии (с учетом чаевых, раздельных счетов и т.д.). Получив предварительный вариант, я сверил рекомендации с актуальными внутренними материалами банка и только после этого предложил решение клиенту.

Отдельный лайфхак — игра с тоном. К примеру, клиент спрашивает: «Чем накопительный счет отличается от вклада?». Вместо того, чтобы каждый раз формулировать ответ с нуля, я могу просто обратиться к ИИ с просьбой подготовить несколько вариантов объяснения: «Объясни разницу в двух вариантах: официально-бюрократическом и простым языком для понимания». И потом просто беру тот вариант, который лучше подходит под конкретного собеседника.

Ответ ИИ

Официальный вариант:

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

Простой вариант:

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

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

2. Подготовка вариантов ответов

В работе с клиентами важно не только знать правильный ответ, но и уметь понятно его объяснить. ИИ помогает быстро подготовить несколько вариантов одного ответа, подобрать более мягкие формулировки для сложных ситуаций и найти разные способы объяснения одного и того же условия.

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

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

Ответ ИИ

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

Для ИП часто важна простота обслуживания и удобство ежедневных операций. Для ООО могут иметь большее значение объемы расчетов, количество платежей, работа с сотрудниками и дополнительные банковские сервисы.

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

Такой вариант ответа помог структурировать информацию и подготовить понятное объяснение для клиента. После этого я проверил условия по актуальным материалам банка и адаптировал ответ под конкретную ситуацию.

Использование ИИ в таких случаях позволяет быстрее подготовиться к встрече и выбрать наиболее подходящий стиль общения с клиентом.

3. Структурирование информации

Если подытожить, то при работе с большим объёмом информации ИИ помогает быстрее разобраться в материалах и привести их к удобному для восприятия виду. Он способен:

• выделить основные мысли и убрать второстепенную информацию;
• разбить большой материал на логические блоки;
• подготовить краткое резюме по документу или инструкции;
• создать удобный чек-лист для выполнения задач;
• составить пошаговую инструкцию по работе с новым продуктом или процессом.

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

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

Здесь самым неожиданным открытием стало то, что ИИ помог мне не только ускорить работу, но и лучше запомнить условия по тарифам. Постоянно сравнивая продукты и проверяя информацию, я со временем стал быстрее ориентироваться в них без дополнительных подсказок. Сейчас в медиа полно паникерских статей: «ИИ делает нас глупее», «Мы разучимся запоминать информацию». Мой личный опыт говорит ровно об обратном.

Где я ИИ не использую

1. Юридически значимые формулировки

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

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

Например, если возникает вопрос, связанный с блокировкой счета в соответствии с требованиями 115-ФЗ, юридическими последствиями или трактовкой нормативных документов, надежнее обращаться к специализированным правовым системам, например к КонсультантПлюс, и внутренним материалам банка. Это связано с тем, что ИИ не всегда корректно работает с большими объемами нормативной информации: он может не учитывать последние изменения законодательства (что я неоднократно проверял), не иметь доступа к актуальной редакции документов или неверно интерпретировать отдельные положения договоров и правил.

Поэтому оптимальный подход — использовать ИИ как помощника для анализа и подготовки информации, а юридически значимые вопросы обязательно проверять по официальным источникам.

2. Финальные ответы клиентам

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

Основные риски при использовании готовых ответов ИИ:

• неточность в формулировке;
• изменение смысла при упрощении информации;
• неправильная интерпретация условий продукта;
• добавление информации, которая не относится к конкретной ситуации клиента.

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

Для подготовки этого резюме я обратился к ИИ, чтобы он помог структурировать информацию по подключенным продуктам и сформировать понятное объяснение. Однако при подготовке ответа ИИ указал, что клиенту был подключен торговый эквайринг, хотя этой услуги не было (и клиент в ней не нуждался).

Если бы я не проверил итоговый текст перед отправкой, клиент мог бы решить, что ему подключили дополнительную услугу.

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

3. Работа с персональными данными

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

Я не передаю:

• персональные данные клиентов;
• номера банковских карт и счетов;
• паспортные данные;
• конфиденциальную внутреннюю информацию банка;
• любую информацию, которая позволяет идентифицировать клиента или получить доступ к защищенным данным.

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

В данной статье подобные примеры не приводятся, так как при работе с ИИ персональные данные клиентов и конфиденциальная информация не использовались. Ответственный подход к работе с информацией позволяет использовать возможности ИИ эффективно, соблюдая требования безопасности.

Основной вывод

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

Он полезен, когда нужно:

• быстрее подготовить черновик;
• упростить сложный текст;
• структурировать информацию;
• найти варианты коммуникации.

Но он не должен заменять профессиональные знания, опыт и ответственность сотрудника.

Главный принцип прост: ИИ помогает подготовить решение, но окончательное решение всегда остаётся за человеком.

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

Правило полуавтоматизации

Главный страх перед алгоритмами обычно связан с потерей контроля. Руководители боятся, что скрипт будет работать криво, отправит клиенту мем или одобрит платеж по неверным реквизитам. Чтобы убрать этот риск, нейросетям отдают исключительно рутину. Ищите регулярный процесс, где есть четкие входные данные и прозрачный результат, который легко проверить визуально. Идеальный старт — пайплайн на базе готового API, заменяющий пару часов ежедневного копипаста. Глобальные проекты по перестройке архитектуры лучше отложить до тех пор, пока вы не научитесь экономить время на мелочах.

Финансы и первичка: избавляемся от ручного ввода

Финансы — удобная стартовая точка для автоматизации. Здесь понятные данные и много механической работы. Вместо ручного сбора цифр из разных источников в конце месяца, процесс ввода можно зациклить с помощью скрипта.

1. Счета в автоматизированную таблицу

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

2. Сверка оплат: ИИ мэтчит банковскую выписку с инвойсами

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

3. Контроль дебиторки: поиск просрочек и автогенерация писем-напоминаний

Контроль дебиторки завязан на человеческом факторе: клиенты забывают перевести деньги, а менеджеры забывают об этом напомнить. ИИ берет на себя отслеживание просрочек: алгоритм находит зависшие счета и самостоятельно генерирует письма-напоминания и оставляет их в черновиках. Менеджеру нужно только отредактировать и отправить письмо.

4. Поиск аномалий: поиск задвоений или скачков расходов

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

5. Сверка заказа и поставки

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

Продажи и лиды: скоринг без участия менеджера

Автоматизация на этапе воронки напрямую влияет на выручку. Каждая минута, которую сотрудник тратит на ручную сортировку — это минус время общения с потенциальным клиентом и потерянные деньги.

6. Сортировка заявок: тегирование лидов по бюджету и срочности

Заявки идут обычно из мессенджеров, форм на сайте и почты. Менеджер открывает всё подряд и пытается понять, кому отвечать первым. Пока он разгребает спам, горячий покупатель уходит к конкурентам. Нейросеть собирает все обращения в единую таблицу, оценивает намерение человека и расставляет приоритеты. Отдел продаж сразу видит тех, у кого высокий бюджет и срочность.

7. Черновики ответов: генерация персонализированных первых сообщений

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

8. КП из переписки: сборка структуры коммерческого из лога чата

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

9. Фоллоу-апы и потерянные сделки: кластеризация причин отказов

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

10. Резюме звонка: транскрибация встреч с выделением договоренностей

После созвона менеджеру нужно заполнять карточку клиента, здесь ИИ-ассистент расшифровывает аудиозапись и выдает короткую выжимку. В ней будут главные потребности, бюджет, обещания и конкретная дата следующего шага.

Управленческие отчеты и инсайты

11. Еженедельная сводка: текстовое саммари из разных метрик

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

12. Анализ рекламы: связка расходов, лидов и продаж

Маркетологи обожают отчитываться лайками и дешевыми кликами. Проблема часто в том, что лайками нельзя заплатить за аренду. Владельцу нужно понимать сквозную аналитику. Алгоритм берет расходы из рекламного кабинета и накладывает их на закрытые сделки из CRM. Становится видно, где бюджет сгорает, и какие каналы генерят бизнесу реальные деньги.

13. Поиск аномалий и прогноз кассовых разрывов

Узнавать о просадках в конце месяца больно. Еще больнее осознать, что завтра нечем платить зарплату. ИИ умеет мониторить отклонения в реальном времени: резко просели продажи конкретного товара или зависли ожидаемые платежи от крупного клиента — скрипт отправляет алерт. Он сводит входящий поток денег с обязательными расходами и заранее показывает риск кассового разрыва. У владельца появляется время для переговоров с поставщиками или ускорения сбора дебиторки.

Чтобы настроить такую аналитику, разработчик в штате не требуется. Таблицы отлично работают через сервис Ajelix, а текст можно генерировать с ChatGPT. Научиться связывать эти инструменты в рабочие процессы можно на курсе «Нейросети на практике: для себя, работы и бизнеса» от Eduson Academy. Программа показывает, как делегировать рутину алгоритмам без навыков программирования.

Клиентский сервис и операционка

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

14. Репутация и контроль качества: парсинг отзывов и проверка ответов менеджеров

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

15. Онбординг и базы знаний: из заметок в инструкции

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

Итого: с чего начать

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

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

Реклама. Рекламодатель: ООО «Эдюсон» ИНН 7729779476, erid: 2W5zFJcrBzy

Откуда вообще берутся ошибки у ИИ

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

В декабре 2025 года исследователи из Университета штата Пенсильвания и Comcast AI Technologies протестировали поведение языковых моделей при одинаковых настройках и запросах. При многократном повторении одних и тех же задач разрыв между лучшим и худшим результатом доходил до 70%.

Что касается практических задач — современные языковые модели решают финансовые задачи с точностью около 67,3%, заметно ниже человеческого уровня. К этому добавляются галлюцинации: модель формирует несуществующую информацию, сохраняя уверенный тон ответа. Попытки повысить достоверность через дообучение пока работают только частично.

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

Open-source против специализированных систем

Распознаванием документов занимаются OCR-системы — технологии оптического распознавания символов. OCR появился ещё в XX веке и развивался задолго до генеративного ИИ. Сегодня такие решения работают в банках, страховании, телекоме и госуслугах — везде, где нужно проверить личность по документу или ввести данные из потока сканов. Качество здесь измеряют точностью распознавания, а её можно посчитать.

Базовые OCR-технологии доступны практически любому разработчику. Есть открытые движки — Tesseract, PaddleOCR, EasyOCR. Они распространяются бесплатно и позволяют быстро собрать собственную систему распознавания документов.

Открытые тесты показывают разброс качества в зависимости от типа документа и условий съёмки. На типовых задачах Tesseract показывал точность 70–85%, PaddleOCR — 90–95%. При работе с финансовыми документами и реальными сканами цифры были скромнее: около 84% у Tesseract и 91% у PaddleOCR.

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

Почему 90% точности — слабый результат

Возьмём систему, которая ошибается с вероятностью 1% и на подлинных документах, и на поддельных. Доля подделок в потоке тоже составляет 1%. Если система пометила документ как подозрительный, какова вероятность, что он действительно поддельный? Интуитивно кажется, что почти 99%, однако на практике все иначе. Расчёт по формуле Байеса даёт ответ:

Вероятность того, что «подозрительный» документ действительно поддельный:

0,99 × 0,01 / (0,01 × 0,99 + 0,99 × 0,01) = 0,5

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

Но если представить, что ИИ ошибается на подлинных документах только в 0,1% случаев, картина меняется и вероятность выявления подделки резко возрастает:

0,999 × 0,01 / (0,01 × 0,999 + 0,99 × 0,001) ≈ 0,91

Вероятность того, что помеченный документ действительно поддельный, вырастает почти до 91%.

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

Что стоит за цифрой 984 из 1000

Вернёмся к кейсу «Росагролизинга». Компания использует технологию Smart Engines для автоматического ввода данных из документов лизингополучателей. По словам компании, из 1000 паспортов 984 обрабатываются без единой ошибки — это касается основного разворота, который в среднем содержит около 200 символов.

Чтобы корректно распознать весь разворот, системе нужно правильно считать каждый из этих 200 символов по очереди. Отсюда можно вывести точность распознавания одного символа. Если X — посимвольная точность, а X в степени 200 — вероятность того, что все символы разворота распознаны верно, уравнение выглядит так:

X²⁰⁰ = 984 / 1000

Чтобы найти X, нужно взять корень 200-й степени из обеих частей уравнения:

X = 0,984^(1/200) ≈ 0,99992

Получается, что точность распознавания одного символа оценивается на уровне 99,99%. Для бизнеса это значит, что 984 из 1000 клиентов проходят онбординг без единого сбоя, участия оператора и ошибок.

Такой результат не выводится сам по себе из общей модели ИИ. Под распознавание удостоверений личности нужна отдельная инженерная работа по трём направлениям:

1. Специализированные датасеты. Обычный набор фотографий печатного текста для этого не подходит. Паспорта изготавливают из специальной бумаги, на них есть защитные элементы, ламинация и голограммы, которые усложняют извлечение данных. Для обучения нужны десятки тысяч размеченных изображений, синтезированных так, чтобы не нарушать 152-ФЗ «О персональных данных» и не содержать информацию о реальных людях.
2. Оптимизация под реальные условия съёмки. На практике паспорт редко снимают идеальным сканом в высоком разрешении. При выездном обслуживании и самообслуживании документ часто фотографируют на весу, под углом или сложенным «книжкой», а на изображении появляются шумы, размытия, тени и блики. Алгоритмы должны выдавать результат и в таких условиях.
3. Понимание структуры документа. Системе мало просто извлечь текст с картинки. Ей нужно находить паспорт на фотографии или в видеопотоке и знать, из каких полей он состоит: где подпись, где строки с именем и фамилией, где машиночитаемая зона.

Что это значит для бизнеса

Чем выше точность, тем меньше работы остаётся людям. На уровне 90% компания заваливает отказами нормальных клиентов и держит отдельных сотрудников, которые перепроверяют документы вручную. На уровне 99,9% и выше вручную проверять приходится в разы меньше: падают расходы на этот штат и снижается риск штрафов за пропущенные подделки.

Бизнес сейчас пытается добиться главных целей:

• меньше ручных проверок — операционный отдел тратит меньше времени на пересмотр документов, помеченных как подозрительные;
• меньше отказов настоящим клиентам — выше конверсия в онбординге и меньше потерянной выручки;
• ниже риск штрафов и судебных разбирательств, особенно в сценариях KYC и антифрод-проверок, где цена пропущенной подделки измеряется конкретными суммами.

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

Итого

Для генерации текста или поиска идей хватает точности в районе 80–90%, и языковые модели справляются с этим хорошо. Для распознавания документов планка выше: 99,9% и больше — минимальное условие, при котором автоматизация вообще начинает работать. Кейс с 984 паспортами из 1000 показывает, как эта цифра считается на практике и какая инженерия за ней стоит. Прежде чем доверять ИИ задачи с высокой ценой ошибки, спросите разработчика, как именно посчитали точность системы.

Ручное тестирование как вход больше не работает

В 2021-м стратегия «вкатиться через мануальное тестирование» ещё работала. Рынок принимал новичков: знаешь, что такое чек-лист и тест-кейс — уже кандидат. Можно было прийти без кода, без понимания API, без SQL и получить оффер на функциональное тестирование, дальше доучиваясь по ходу.

Дальше рынок начал двигаться, и двигался он быстрее, чем кажется внутри компании. В 2022-м в вакансиях QA появились приписки: «желательно знание автоматизации», «опыт с API», «базовый SQL». Слово «желательно» сбивает с толку — звучит как бонус, а на деле это знак, куда поедут требования через пару лет. И они поехали: то, что в 2022-м было «желательно», к 2024-му стало обязательным условием.

К 2024 году ситуация выглядит уже так: смотришь вакансии и ни в одной не встречаешь формулировку «требуется ручной тестировщик». Вместо неё везде QA Engineer со знанием автоматизации, опыт в финтехе, CI/CD, Docker, Kubernetes, углублённое понимание API. К концу 2025-го добавляется ещё и опыт работы с ИИ и LLM.

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

Вывод для тех, кто планирует вход в 2026-м: начинать с чек-листов смысла мало, потому что это тупиковая ветка, с которой потом всё равно придётся переучиваться. Логичнее сразу собирать ту базу, которая позволит работать с первого дня и не упираться в потолок. Что в эту базу входит, дальше по разделам.

Научиться понимать архитектуру

Проектировать системы вам не придётся, это работа архитектора. Задача тестировщика — представлять, как устроено то, что он тестирует, чтобы видеть всю цепочку, а не отдельную кнопку.

На практике это четыре вещи:

1. Как сервисы общаются между собой: синхронно через HTTP, когда один ждёт ответа другого, или асинхронно через очередь сообщений, когда событие кладётся в брокер и подбирается, когда получатель готов.
2. Где хранятся данные и как к ним обращаются разные компоненты.
3. Что произойдёт, если один из сервисов упадёт, и кто из соседних это заметит.
4. Как запрос трансформируется на каждом шаге пути от клиента до ответа.

Зачем это тестировщику. Пока вы тестируете поверхностно — нажал, посмотрел результат, — вы можете зафиксировать, что баг есть, но не объясните почему. На вопрос «где сломалось» ответа нет, потому что система для вас непонятная. Как только появляется понимание потоков данных, сразу становится лучше. Вместо «кнопка не работает» вы говорите: запрос пришёл в Gateway, прошёл в Core-сервис, событие легло в Kafka, консьюмер его прочитал, но в базе нужной записи нет — значит, ищем разрыв на участке между консьюмером и базой. Это уже баг, с которым можно идти к разработчику.

Лучший способ это уложить в голову — поднять микросервисное приложение локально и посмотреть, как сервисы взаимодействуют. Перед практикой имеет смысл прочитать «Designing Data-Intensive Applications» Мартина Клеппмана (на русском вышла как «Высоконагруженные приложения»). Кода там нет, зато подробно разобрано, как системы устроены изнутри, — для QA это полезнее, чем уметь самому писать сервисы.

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

• Microservice Kafka Sample — три сервиса (заказы, доставка, выставление счёта), между ними Kafka, у каждого своя база PostgreSQL, поднимается через docker-compose up. Создаёте заказ в одном сервисе, через какое-то время накладная и статус доставки появляются в других. Удобно трассировать запрос и искать, где он застрял.
• Microservices with Spring Boot and Kafka Demo Project — посложнее: заказы, платежи, склад, распределённые транзакции по паттерну SAGA, поддержка Docker Compose и Testcontainers. Хорошо показывает, что происходит с транзакцией, когда она идёт через несколько сервисов и один из них падает.

Если хочется теории вместе с практикой, на Stepik есть курс «Microservices — паттерны и практика построения микросервисов»: русскоязычный, разбирает паттерны взаимодействия, асинхронные системы, RabbitMQ. Он заточен под понимание концепций, а не под написание продакшн-кода, — то, что нужно.

Три технологии, которые спрашивают всегда

1. HTTP и REST API. REST — это договорённость между клиентом и сервером о том, как они общаются. Клиент просит: дай данные о пользователе с ID 42. Сервер отвечает JSON-ом и кодом: 200 — всё нашлось, 404 — такого пользователя нет, 403 — прав не хватает. Тестировщик, который умеет вызывать API через Postman, curl или код, проверяет логику системы мимо интерфейса — раньше и точнее, чем через клики по экрану. Базовый минимум: методы (GET, POST, PUT, DELETE), коды ответов (2xx, 4xx, 5xx), заголовки, структура JSON, аутентификация.
2. Базы данных и SQL. Почти каждый дефект оставляет след в базе: либо лежит некорректная запись, либо записи нет вообще. Написать SELECT с джойнами, проверить результат агрегации, отловить дубли — ежедневная работа QA-инженера. На собесе это спрашивают как данность, а не как редкий бонус.
3. Брокеры сообщений и Kafka. Kafka даёт сервисам общаться асинхронно: один кладёт событие в топик, другой забирает его, и никто не висит в ожидании. В распределённых системах это стандарт. Если данные не появились там, где их ждали, возможно, они застряли в очереди, а не пропали из базы. Это две разных ситуации, и путать их дорого для бизнеса.

Важное предупреждение, чтобы не отпугнуть: писать эти сервисы самому QA не нужно. Цель — понять, что происходит внутри, когда данные идут от одного сервиса к другому. Поднял проект, посмотрел Postman, почитал логи, остановил контейнер, посмотрел на последствия — этого достаточно, чтобы общаться с командой разработки.

Научиться читать логи

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

Выглядит типичная диагностика так:

• Прилетает алерт: сервис X начал возвращать 500-е ошибки.
• Открываете Kibana, фильтруете по временному интервалу и имени сервиса, чтобы отсечь лишний шум.
• Находите трейс конкретного запроса — от входящего HTTP-вызова до ответа базы данных.
• В трейсе видите stacktrace с исключением в определённом классе и конкретным сообщением.
• Дальше тянете за эту нитку до корневой причины: например, оказывается, что упал не сам сервис, а внешний, к которому он обращался, и причина — таймаут.

Помимо Kibana для разбора логов в работе пригодится связка Grafana и Prometheus для мониторинга метрик. Логи отвечают на вопрос «что именно сломалось в этом запросе», метрики показывают картину шире: когда началась деградация, какой сервис первым ушёл в красное, как менялась нагрузка перед инцидентом. Вместе они дают и точку отказа, и контекст вокруг неё.

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

Зачем QA язык программирования

Помимо скорости код даёт понимание работы команды разработки. Когда QA пишет автотесты на том же языке, на котором разработчики пишут продукт, стирается граница между «вашим» и «нашим» кодом. Проблему можно обсудить на уровне реализации, быстро получить консультацию, а иногда разработчик и сам запускает ваши тесты, чтобы проверить свою фичу, или вносит правку в тестовый код, когда видит, в чём причина нестабильности.

Конкретно код у QA уходит на несколько вещей:

• Автотесты — заменяют ручной прогон регресса, гоняются хоть каждую ночь.
• Тестирование API — написать авторизацию, отправить запрос, проверить JSON-схему ответа.
• Генерация тестовых данных — создать тысячи записей с разными параметрами под нагрузочные и граничные сценарии.
• Верификация в базе — SQL-запросы, которые проверяют, что в данных лежит именно то, что должно.
• Shift-left — писать тесты параллельно с разработкой, ещё на этапе требований, чтобы дефекты ловились раньше.

С чего начинать. Java или Python — хорошие первые языки, оба распространены в автоматизации и под оба полно вакансий. Но учить язык лучше в контексте задач тестирования, а не абстрактно по учебнику: сразу написать первый UI-тест через Selenium, сделать HTTP-запрос через RestAssured или requests, дёрнуть SQL-запросом реальную базу.

Инженерное мышление вместо «кнопка не работает»

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

Складывается это мышление из нескольких рабочих привычек:

1. Спрашивать «почему», а не только «что». Не «кнопка не нажимается», а «почему запрос возвращает 403 именно для этой роли».
2. Держать в голове систему целиком: как правка в одном сервисе аукнется в соседних через Kafka-события, общую базу или контракты API.
3. Заранее прикидывать риски: что сломается первым под нагрузкой, какие граничные случаи опаснее остальных. Сюда же относится участие в проектировании: дефект, пойманный на этапе требований, обходится примерно в десять раз дешевле, чем тот же дефект, найденный в продакшене.
4. Оперировать цифрами: время прогона регресса, покрытие тестами, количество инцидентов.

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

Итого

Если собрать роадмап в один список, маршрут получается такой:

• Разбираться в архитектуре и поднимать демо-микросервисы локально;
• Знать HTTP с REST, SQL и брокеры вроде Kafka;
• Уметь читать логи, потому что в проде это ваш основной инструмент;
• Освоить язык под автоматизацию;
• И приучать себя думать потоками данных, а не кнопками.

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

И ещё одно наблюдение, ради которого статья была написана. Рынок QA за пять лет переписал требования дважды и продолжит переписывать. Гнаться за конкретной строчкой в вакансии бессмысленно — она устареет к следующему собесу. Работает другая установка: целиться не в «войти в IT через тестирование», а в «стать инженером, который умеет тестировать». Первое даёт оффер на год, второе — профессию, которая переживёт любую следующую волну требований.

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

Разбираемся, как устроена система Minions, какие задачи она решает и чему из опыта Stripe могут научиться другие компании. Статья основана на публичных материалах ByteByteGo и Stripe Engineering Blog.

Ключевые выводы:
— Stripe мержит более 1300 PR в неделю, созданных полностью автономными ИИ-агентами
— Minions — это unattended-агенты: они не требуют наблюдения или пошагового одобрения
— Архитектура построена на «блюпринтах» — гибридах жёсткого пайплайна и агентных циклов
— Главный секрет успеха — не модель, а developer-инфраструктура: изолированные окружения, быстрые тесты и чёткие ограничения
— Если агент не справился за два цикла CI — задача возвращается человеку

Масштаб — цифры и факты

Stripe обрабатывает более триллиона долларов платежей в год. Кодовая база компании — сотни миллионов строк кода, преимущественно на Ruby с типизацией Sorbet. Это относительно редкий стек, с которым LLM практически не сталкивались при обучении.

На этом фоне цифры Minions выглядят особенно впечатляюще:

• 1300+ PR в неделю — полностью автоматические, без единой строки человеческого кода
• Типы задач — миграции кода, обновление зависимостей, исправления безопасности, рефакторинг
• Время запуска агента — менее 10 секунд от запроса до начала работы
• Параллельность — один инженер может запустить 5-6 агентов одновременно

Важно понимать: Stripe не считает каждый PR идеальным. Частично корректный пулл-реквест, который инженер доработает за 20 минут, — это уже серьёзный выигрыш. Система спроектирована с учётом этой реальности.

Архитектура агентов

Изолированные окружения — devbox-ы

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

Stripe уже имел всё это. Их «devbox-ы» — облачные машины, предзагруженные с полной кодовой базой, инструментами и сервисами. Они поднимаются за 10 секунд, потому что Stripe заранее провизионирует и прогревает пул машин — клонирует репозитории, прогревает кеши и запускает фоновые сервисы. Инженеры и раньше использовали по одному devbox-у на задачу, а один инженер мог держать полдюжины одновременно. Агенты просто встроились в этот паттерн.

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

Блюпринты — гибрид workflow и агента

Есть два классических подхода к оркестрации LLM-систем:

• Workflow — фиксированный граф шагов, где каждый шаг делает одну конкретную вещь, а последовательность предопределена
• Agent — цикл, в котором LLM сама решает, что делать дальше, на основе результатов предыдущих действий

Workflow предсказуемы, но негибки. Агенты гибки, но ненадёжны. Stripe построил нечто среднее — «блюпринты» (blueprints).

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

• Шаг «реализуй фичу» или «исправь ошибки CI» — полный агентный цикл с инструментами и свободой действий
• Шаг «запусти линтеры» — захардкожен, всегда выполняется одинаково
• Шаг «запуши ветку» — захардкожен, строго по шаблону PR компании

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

Контекст — как не утонуть в сотнях миллионов строк

У LLM ограниченное контекстное окно. Если загрузить все правила и конвенции глобально, контекст заполнится до того, как агент начнёт работать. Stripe использует глобальные правила «очень осторожно» — вместо этого они привязывают правила к конкретным директориям и паттернам файлов. Когда агент перемещается по файловой системе, он автоматически подхватывает только релевантные правила.

Для информации, которая не живёт в файловой системе, Stripe построил централизованный сервер Toolshed. Он хостит почти 500 инструментов через MCP (Model Context Protocol) — открытый стандарт, который даёт агентам единый способ вызывать внешние сервисы. Через MCP агенты получают доступ к внутренней документации, деталям тикетов, статусам билдов, результатам поиска по коду и многому другому.

Но больше инструментов — не значит лучше. Агенты работают лучше с тщательно подобранным подмножеством, релевантным их задаче. Stripe даёт Minions небольшой набор по умолчанию и позволяет инженерам добавлять дополнительные при необходимости.

Модели и обратная связь

Stripe не раскрывает конкретные модели, которые используют Minions, но архитектура сознательно абстрагирована от конкретной LLM. Ключевое значение имеет не модель, а инфраструктура обратной связи:

1. Локальный линтинг — запускается при каждом push за менее чем 5 секунд. Фоновый демон заранее вычисляет, какие правила линтинга применимы, и кеширует результаты
2. CI — выборочно запускает тесты из батареи в 3+ миллиона тестов. Автофиксы применяются автоматически для известных паттернов ошибок
3. Повторная попытка — если после автофикса ошибки остались, агент получает ещё один шанс исправить и запушить

Затем — стоп. Максимум два цикла CI. Если код не проходит после второго push-а, ветка возвращается инженеру. Это ограничение осознанное: LLM показывают убывающую отдачу при повторных попытках решить ту же проблему. Больше раундов — больше токенов и вычислений без пропорционального улучшения.

Какие задачи решают агенты

Minions лучше всего справляются с задачами, которые хорошо определены, повторяемы и поддаются автоматической проверке:

• Миграции кода — перевод со старых API на новые, обновление паттернов использования библиотек
• Обновление зависимостей — bump версий, адаптация кода к breaking changes
• Исправления безопасности — применение патчей по известным уязвимостям
• Рефакторинг — переименование, перемещение модулей, приведение к единому стилю
• Мелкие баг-фиксы — исправления, которые накапливаются в on-call очереди за ночь

Чего Minions не делают:

• Не проектируют новую архитектуру
• Не принимают продуктовых решений
• Не пишут код, требующий глубокого понимания бизнес-логики
• Не работают с задачами, которые нельзя проверить автоматическими тестами

Это ключевое отличие от «attended» инструментов вроде Cursor или Claude Code, которые работают вместе с разработчиком. Инженеры Stripe используют и те, и другие — для разных типов задач.

Результаты и метрики

Stripe не публикует детальные внутренние метрики, но из публичных материалов и выступлений инженеров можно выделить ключевые результаты:

• 1300+ PR в неделю — объём, эквивалентный работе десятков инженеров
• Сдвиг от написания к ревью — инженеры не исчезли, но их роль изменилась: вместо написания кода они проверяют код, созданный агентами
• Частично корректные PR — даже неидеальные результаты экономят время, потому что доработка занимает 20 минут вместо нескольких часов с нуля
• Масштабирование без найма — рутинные задачи снимаются с инженеров, позволяя команде фокусироваться на сложной архитектурной работе

Четыре уровня системы, которые обеспечивают эти результаты:

1. Изолированные окружения — безопасные параллельные рабочие пространства
2. Гибридная оркестрация — детерминированные гарантии плюс агентная гибкость
3. Курированный контекст — правильная информация без перегрузки
4. Быстрая обратная связь с жёсткими лимитами на итерации

Чему учит опыт Stripe

Главный инсайт Stripe: инвестиции в продуктивность разработчиков, сделанные за годы до появления LLM, дали неожиданные дивиденды, когда агенты появились в рабочем процессе.

Уроки, которые можно вынести:

1. Начинайте не с выбора модели, а с инфраструктуры. Окружения разработчика, тестовая инфраструктура, пайплайны обратной связи — если они хороши, агенты получат от них выгоду. Если нет — никакая модель не спасёт
2. Разделяйте детерминированное и агентное. Линтинг, push, создание PR — это не задачи для LLM. Захардкодьте то, что можно захардкодить
3. Ставьте жёсткие ограничения. Максимум два цикла CI — один из самых важных дизайн-решений Stripe. Знать, когда остановиться, так же важно, как знать, с чего начать
4. Начинайте с рутины. Миграции, обновления зависимостей, патчи безопасности — это идеальные первые кандидаты для автономных агентов
5. Человеческое ревью никуда не уходит. Роль инженера смещается от написания кода к проверке кода. Это не замена людей, а усиление команды

Когда стоит задуматься о внедрении подобного подхода? Если у вас уже есть: надёжная CI/CD-инфраструктура, изолированные окружения для разработки и достаточно рутинных задач, которые поддаются автоматизации.

Часто задаваемые вопросы

Какую LLM используют Minions в Stripe?

Stripe не раскрывает конкретную модель. Архитектура Minions сознательно абстрагирована от конкретной LLM — ключевую роль играет инфраструктура (devbox-ы, блюпринты, MCP-инструменты), а не сама модель. Это позволяет менять или обновлять модель без переписывания всей системы.

Могут ли Minions заменить разработчиков?

Нет. Minions решают рутинные, хорошо определённые задачи — миграции, обновления зависимостей, патчи. Архитектурные решения, продуктовое проектирование и задачи с нетривиальной бизнес-логикой по-прежнему требуют человека. Роль инженера смещается от написания к ревью кода.

Можно ли повторить подход Stripe в небольшой компании?

Принципы масштабируемы: изолированные окружения, гибрид детерминированных и агентных шагов, курированный контекст, жёсткие лимиты на итерации. Но для полноценной реализации нужна зрелая CI/CD-инфраструктура и достаточный объём повторяемых задач. Начните с малого — автоматизируйте один тип рутинной задачи и расширяйте по мере роста доверия к системе.

Что такое MCP и зачем он нужен агентам?

Model Context Protocol (MCP) — это открытый стандарт, который даёт ИИ-агентам единообразный способ вызывать внешние сервисы. Stripe использует MCP для подключения почти 500 внутренних инструментов — от поиска по коду до статусов билдов. Благодаря MCP агенты получают доступ к нужной информации через стандартизированный интерфейс.

Выводы

Опыт Stripe показывает: будущее разработки — это не замена инженеров агентами, а построение инфраструктуры, в которой агенты становятся ещё одним типом участников инженерного процесса. 1300 PR в неделю без единой строчки человеческого кода — это результат не прорыва в ИИ, а многолетних инвестиций в developer experience.

Ключевой вопрос не «какую модель выбрать», а «готова ли наша инфраструктура к агентам». Изолированные окружения, быстрые тесты, чёткие ограничения, курированный контекст — всё это можно и нужно строить уже сейчас, вне зависимости от того, когда именно вы запустите первого агента.

Если тема ИИ-агентов в разработке вам интересна, рекомендуем изучить оригинальные статьи в Stripe Engineering Blog.

Кому это будет нужно:

• Платформенным аналитикам — меньше рутинного ревью, больше времени на рабочие задачи.
• Продуктовым аналитикам и разработчикам — быстрая обратная связь, понятные и шаблонные требования для проекта.

Откуда растёт проблема

Прежде чем описывать решение, давайте поймем контекст.

Перед релизом любой фичи команда готовит поставку: у разработчика — code review, у аналитика — ревью документации. Весь процесс идёт по workflow в Jira, и один из обязательных этапов — Docs review.

За этот этап отвечают платформенные аналитики: они дежурят по очереди и проверяют поставки. Их задача — убедиться, что документация написана по стандарту и отражает все новые изменения по продуктам. Хранится всё в едином Confluence-пространстве платформы, и порядок там очень нужен: документацию читают не только аналитики разных команд, но и саппорт.

Звучит адекватно. Но на практике вылезают три проблемы:

1. Задержки. У платформенного аналитика помимо ревью куча других задач. Когда поставок много — Docs review начинает тормозить весь процесс подготовки к релизу.
2. Усталость ревьювера. Большой поток однотипных проверок выматывает даже самого внимательного, поэтому риск нужно было сократить.
3. Человеческий фактор. Несмотря на наличие стандарта, разные ревьюверы могут расставлять акценты по-разному. Аналитик продуктовой команды никогда не знает наверняка, на что обратят внимание в этот раз.

Всё это бьёт по времени поставки и непонятно растягивает подготовку к релизу — особенно когда релизиться нужно быстро.

Что пробовали раньше

Прежде чем идти в сторону AI, рассмотрели два очевидных варианта.

Вариант 1: убрать ревью совсем.

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

Вариант 2: алгоритмическая автоматизация без AI.

Теоретически можно написать набор проверок на if-else. Но у документации нет синтаксиса, как у кода — каждый аналитик пишет немного по-своему. Поддержка такого алгоритма со временем станет дороже, чем просто делать ревью руками.

Почему AI-агент

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

Вот конкретные факты, которые мы собрали внутри команды:

• LLM умеет понимать суть написанного, а не только искать точные совпадения, если документация написана по-разному — для нейронки это не проблема.
• Когда требования меняются, в большинстве случаев достаточно поправить промпт. Аналитик справится сам, без участия разработчика.
• У агента одна задача — ревью, он делает её сразу, не надо ждать, пока освободится дежурный аналитик.
• Агент интегрируется в существующий Jira-workflow. Для команд ничего не меняется — агент работает в фоне.
• У агента понятный набор инструкций.

Архитектура агента

Desmond — экосистема агентов. Desmond Docs Reviewer — task-oriented AI-агент для автоматизации ревью внутренней документации на платформе Альфа-Онлайн.

Стек:

• Язык: Java 21 + Spring AI
• Инфраструктура: Docker + Kubernetes во внутреннем AI-кластере банка
• Модель: gpt-oss-120b — внутренний продукт банка AlfaGen, развёрнутый локально
• Интеграции: Jira (webhook + REST API + Kafka), Code Review Agent (A2A через MCP), LLM API

Точка входа — webhook из Jira. Задача переходит в нужный статус → триггерится webhook → агент получает событие и начинает работу.

На входе агент имеет три сущности:

• описание изменений (фича)
• ссылку на документацию в Confluence
• ссылку на Pull Request разработчика

Дальше — четыре шага.

Как агент решает задачу пошагово

Посмотрим на работу агента со стороны процесса и распишем детально каждый.

Шаг 1. Нужна ли вообще проверка?

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

Агент анализирует описание задачи и diff PR. Смотрит на примеры из промпта и выдаёт решение: техническая доработка или нет, плюс короткое обоснование — не больше 30 слов.

Типовые технические доработки, которые не требуют проверки: обновление библиотек, рефакторинг тестов, исправление линтера, дизайнерские правки без влияния на UX. Есть и исключения — например, изменение deeplink-параметров или перемещение приложения в новый репозиторий. Всё это прописано в промпте явно.

На реальных задачах получили 89,7% корректных ответов (27 из 30). Для старта приемлемо, но будем улучшать.

Если доработка техническая — агент пишет комментарий в задачу и переводит её в следующий статус. Дальше не идёт.

Общий сценарий в коде выглядит так:

Шаг 2. Есть ли в документации описание фичи?

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

Отдельно проверяется раздел «7. История изменений» — изменение должно быть там зафиксировано.

Проблема с токенами. Документация бывает большой — и она не влезает в контекст целиком. Решение: разбить на чанки и анализировать по частям.

Стратегия нарезки простая — равномерно по количеству символов, семантическое деление по разделам здесь не критично: мы ищем одни и те же фрагменты вне зависимости от их положения в структуре.

Чтобы не терять контекст на границах, используем перекрытие (overlap): к каждому чанку добавляем хвост предыдущего и заголовок его раздела. Размер чанка рассчитывается по формуле с коэффициентом, подобранным эмпирически — с запасом на колебания длины токенов.

Смысл её в том, чтобы заранее рассчитать максимально допустимое количество символов на чанк (C_chunk), включая резерв под перекрытие (C_dup) и заголовок. Коэффициент r был подобран эмпирически — с запасом, чтобы учесть возможные колебания в длине токенов.

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

Пример ответа, когда описание фичи найдено:

Пример ответа, когда описание фичи не найдено:

Шаг 3. Соответствует ли документация стандарту?

Это самая сложная часть — со звёздочкой. Нужно пройтись по каждому разделу документа и сверить его с требованиями стандарта. Документация структурирована: шапка, основная информация, предусловия, постусловия, сценарии использования, алгоритм, подробное описание, история изменений.

Возьмем кусочек стандарта, описывающий шапку страницы:

Стандарт для LLM — это не то же самое, что стандарт для людей

Когда мы первый раз запустили проверку, скормили агенту существующий стандарт как есть. Результат нам не понравился: LLM интерпретировала одни и те же требования по-разному, часть пунктов игнорировала, часть выполняла непредсказуемо.

Причина в том, что стандарт писался для аналитиков, которые понимают контекст и в нём много неявных допущений — «вставьте ссылку на команду», «укажите репозиторий» — и ни слова о том, как именно это должно выглядеть.

Вот типичные вопросы, на которые у стандарта не было ответа:

• Ссылка на команду — это Confluence, Notion или Jira?
• Jira-ссылка — это макрос или обычный URL?
• Как проверить корректность ссылки на репозиторий?
• Всегда ли обязательна эта таблица, или бывают исключения?

Переписали стандарт в LLM-читаемый формат, руководствуясь простыми принципами:

• Каждое требование сформулировано явно и однозначно.
• Для каждого поля приведены примеры правильного и неправильного заполнения.
• Никаких «подразумевается» и «как правило».

Вот как выглядит фрагмент переписанного стандарта для шапки документа:

Кусочек 2

Кросс-раздельные проверки

Часть требований касается не одного раздела, а согласованности между несколькими. Например: все сервисы, упомянутые в колонке Git Middle шапки, должны иметь ссылку на документацию в разделе «Основная информация».

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

Один из примеров кросс-проверок:

Chunking strategy

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

Дано:

• LLM-читаемый формат, разбитый по разделам
• Документация, также структурированная по разделам

Решение:

1. Разделяем на чанки документацию. 1 чанк = 1 раздел.

2. Разделяем на чанки стандарт. 1 чанк = 1 требование.

3. Сопоставляем чанки стандарта и документации между собой:

Проверка оформления:

1 чанк (раздел) документации ~ 1 чанку стандарта (требование к разделу).

Кросс-проверки:

1 чанк кросс-проверки (отдельный раздел с кросс-проверками) ~ n чанкам (разделам) документации.

4. Отправляем в LLM запросы на проверку по каждому соответствию.

5. Собираем в единый отчет.

Примеры:

Проверка оформления

• 1 чанк стандарта

• 1 чанк документации (представлено графически для наглядности. В реальности данные передаются в LLM в HTML-формате)

Кросс-проверка

• 1 чанк стандарта:

• 2 чанка документации:

Чанк 1

Чанк 2

Итоговый промпт:

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

Как выглядит код:

Мы видим, что при использовании чанков LLM перестала пропускать требования, проверки стали стабильнее, ответы — содержательнее.

Пример ответа LLM до чанкования в свободном формате:

Пример ответа LLM после чанкования в JSON-формате. Приведу пример анализа только одного чанка (раздел Алгоритм), т.к. в сумме по чанкам получается тот самый объёмный текст длиной в 200-250 символов.

А что если раздел слишком большой?

В таком случае мы используем chunking strategy из шага 2 и агрегируем результаты с помощью немного сумасшедшего 💊, но работающего промпта.

Агент отправляет запрос на проверку по каждому соответствию, затем собирает всё в нормальный отчёт. Изначально отчёт выходил на 200–250 строк — неудобно читать, мы добавили отдельный шаг финального саммари — сократили до 50 строк без потери содержания.

Технические грабли

Нестабильность ответов LLM

Одна из первых проблем — LLM отвечала в произвольном формате. Иногда JSON, иногда текст, иногда что-то среднее. Решение: Structured Output в Spring AI. Ответ всегда приходит в заданной структуре — никакой самодеятельности.

Лимит токенов

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

Скрытые элементы Confluence

Confluence отдаёт HTML, и часть контента скрыта в элементах, которые не видны при обычном просмотре страницы. Агент работает напрямую с HTML, в котором остаются только нужные для обработки теги — это позволяет не терять данные, которые визуально не отображаются

Долгое время обработки

Первые версии работали медленно: несколько запросов к LLM шли последовательно. Переключились на Java Virtual Threads — параллельная обработка чанков сократила медианное время ревью с 1:20 до 0:26.

Как это выглядит в коде:

Что конкретно упростилось

• Аналитики продуктовых команд стали прогонять документацию через агента ещё до этапа ревью — как самопроверку.
• При повторном ревью после правок не надо ждать человека — достаточно перезапустить агента.
• Проверка корректности ссылок и форматов полностью снята с плеч аналитиков.

Ограничения

1. Макеты — проверяется только их наличие, содержимое агент не анализирует.
2. Нестандартная структура — если документация сильно отклоняется от шаблона, автоматическая проверка даёт менее надёжный результат.

Что дальше

Идеи в работе и на горизонте:

• Автоматический аппрув документации, если все проверки прошли успешно.
• Подключение проверок документации по микросервисам, не только фронтенд.
• Проверка полноты документации через код — что позволит закрыть ревью почти полностью, за исключением нестандартных кейсов.

Статья предполагает, что OpenClaw у вас уже развёрнут. Если нет — вот инструкция от RouterAI по установке.

Как использовать

• Копируете промпт
• Отправляете в OpenClaw
• Отвечаете на уточняющие вопросы агента
• Получаете работающую автоматизацию

1. Обработка входящих документов из чатов (счета, акты, КП)

Документы из Telegram автоматически классифицируются, переименовываются по шаблону и раскладываются по папкам с уведомлением ответственных.

Как это работает

OpenClaw отслеживает входящие сообщения с вложениями. При получении PDF или изображения — запускает OCR при необходимости, извлекает ключевые данные (номер, дата, контрагент, сумма), переименовывает файл и сохраняет в нужную директорию.

Промпт

Что подготовить

• Канал/чат для входящих документов
• Канал бухгалтерии для уведомлений
• Путь к директории для хранения файлов

Итог

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

2. Мониторинг и исследование конкурентов

Ежедневный отчёт об активности конкурентов: новые продукты, изменения цен, вакансии, упоминания в прессе.

Как это работает

OpenClaw по cron-расписанию обходит список источников (RSS, сайты, новостные порталы), сравнивает с предыдущим отчётом и присылает только реальные изменения.

Промпт

Что подготовить

• Список конкурентов (названия, URL сайтов, RSS если известны)
• Отрасль и ключевые слова для новостного поиска
• Канал доставки отчёта

Итог

Начните с 2–3 конкурентов и RSS-лент — это самый надёжный источник. Скрапинг публичных страниц может ломаться при изменении вёрстки, так что проверяйте отчёты в первую неделю.

3. Утренний дайджест по расписанию

Сводка за 2 минуты вместо получаса ручной проверки почты, чатов и новостей.

Как это работает

По расписанию OpenClaw собирает данные из подключённых источников (почта, календарь, мессенджеры, новости) и присылает одно сообщение с приоритетами.

Промпт

Что подготовить

• Какие источники подключены (почта, календарь, мессенджеры)
• Список важных отправителей/чатов
• Тематика новостей
• Канал доставки

Итог

Первую неделю следите за качеством — скорее всего, придётся подправить список важных отправителей и тематику новостей. Если используете вместе с кейсом 4 (Email-triage), разграничьте зоны ответственности: дайджест — обзор за день, triage — обработка каждого письма в реальном времени.

4. Email-triage: Inbox Zero с умной обработкой

Автоматическая сортировка входящей почты: важные письма — в приоритет, рассылки — в архив, типовые запросы — черновик ответа.

Как это работает

OpenClaw проверяет почту каждые 15 минут, классифицирует письма и выполняет действия: уведомляет, архивирует, готовит черновики или помечает для ручной обработки.

Промпт

Что подготовить

• Почтовый ящик (Яндекс Почта, Mail.ru, Gmail, Outlook или IMAP)
• Список VIP-отправителей
• Примеры типовых запросов для обучения классификации
• Канал для уведомлений

Итог

Начните с автоархивации рассылок — это безопасно и сразу разгружает инбокс. Черновики ответов подключайте, когда убедитесь в качестве классификации. Папку «На проверку» первое время проверяйте ежедневно. Если используете вместе с кейсом 3 (утренний дайджест), почтовую часть дайджеста можно упростить до сводки по категориям из triage.

5. Управление умным домом/офисом через чат

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

Как это работает

OpenClaw подключается к Home Assistant (или другой системе) через API и выполняет команды из чата. Простые действия — сразу, сценарии — по расписанию.

Промпт

Что подготовить

• Какая система умного дома (Home Assistant, Яндекс, Mi Home или другая)
• URL и API-токен для подключения
• Список устройств и их названия
• Какие сценарии по расписанию нужны

Итог

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

6. Помощник для защиты прав потребителя

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

Как это работает

Вы описываете проблему, агент определяет тип спора, подбирает применимые нормы, генерирует текст документа и ставит напоминание о дедлайне ответа.

Промпт

Что подготовить

• ФИО, адрес и контакты для шапки документа
• Документы по спору (чеки, договор, переписка с продавцом)
• Описание проблемы: что купили, когда, что пошло не так

Итог

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

7. Проактивный мониторинг безопасности

Ежедневная проверка зависимостей проектов на известные уязвимости с уведомлениями по критичности.

Как это работает

OpenClaw по расписанию парсит файлы зависимостей, сверяет версии пакетов с базой CVE и присылает отчёт с приоритизацией по CVSS.

Промпт

Что подготовить

• Пути к репозиториям/директориям для мониторинга
• Канал для уведомлений
• Есть ли пакеты, которые нужно исключить из проверки

Итог

Хорошая первая линия обороны, но не замена полноценному аудиту. Для критичных систем используйте Snyk, Trivy или Dependabot параллельно.

Ещё идеи

Что делают другие пользователи:

• Парсинг веб-страниц и сохранение саммари в базу знаний
• Поиск товаров на маркетплейсах по списку покупок и добавление дешёвых вариантов в корзину
• Сбор статистики из рекламных кабинетов и отправка сводки команде
• Переименование файлов в папке по содержимому или дате
• Мониторинг новостных сайтов по теме AI с публикацией саммари в Telegram-канал команды
• Проверка битых ссылок на сайте и отчёт по 404-м
• Поиск кандидатов на hh.ru по критериям и выгрузка в таблицу
• Мониторинг цен на авиабилеты с уведомлением при снижении
• Анализ серверных логов за сутки и выделение критических ошибок
• Перевод файлов локализации (JSON) на новые языки с сохранением структуры
• Сбор финансовых показателей конкурентов из открытых источников в Excel

Рекомендации

Начните с малого. Выберите 2–3 кейса и доведите до ума, прежде чем автоматизировать всё подряд.

Итерируйте. Первая версия промпта редко бывает идеальной. Корректируйте по результатам.

Следите за агентом. Первое время проверяйте, что автоматизация делает то, что вы ожидаете.

Не забывайте о безопасности. HTTPS, минимальные права доступа, секреты — в защищённом хранилище. Агент с доступом к вашим системам и API-ключам может натворить дел при ошибке в настройке.

Заключение

Возможности OpenClaw + RouterAI не ограничиваются этими семью сценариями — вы можете описать агенту любую задачу или попросить его создать нужную автоматизацию с нуля.

ChatGPT удерживает первое место в вебе, хотя доминирование ослабло — мобильная аудитория Gemini достигла половины от ChatGPT. Grok от xAI совершил главный рывок: с нуля до 20 млн активных пользователей и четвёртое место в веб-рейтинге. DeepSeek потерял позиции: −22% в мобильном сегменте и −40% в вебе.

В России картина другая. Среди молодёжи до 35 лет лидируют ChatGPT (64%), Алиса AI (46%) и DeepSeek (40%). В старшей группе (51+) первым стал GigaChat (54%) — локальные решения сильны.

Тренды

От чат-ботов к агентам. ИИ-агенты самостоятельно планируют действия, используют внешние инструменты и выполняют сложные задачи. IDC прогнозирует: к 2030 году 45% крупных организаций внедрят такие системы.

ИИ на устройстве. Модели работают прямо на смартфонах и ноутбуках — меньше задержки, выше конфиденциальность. Рынок встроенного ИИ оценивают в $11,54 млрд.

Открытые модели сократили разрыв с коммерческими: по AI Index Report, разница в производительности упала с 8% до 1,7% за год.

Нерешённые проблемы

Кризис доверия. 70% россиян распознают контент от ИИ, а 56% негативно относятся к брендам, которые это скрывают.

Приватность. Соцсети с ИИ-агентами столкнулись с утечками личных данных.

Слабые рассуждения. Модели по-прежнему плохо справляются с многошаговой логикой.

Инвестиции в ИИ в США достигли $109,1 млрд, доля компаний с ИИ выросла с 55% до 78%.

Если хотите научиться работать с нейросетями на профессиональном уровне — от промптов до автоматизации задач — посмотрите курс «Нейросети для увеличения дохода» от Академии ТОП.

Текстовые модели

Современные модели не просто пишут грамотно — они адаптируются к стилю, запоминают терминологию проекта и тон бренда.

GPT-5: глубокое понимание контекста

Доступ через агрегаторы типа RuGPT

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

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

Доступность в России: через агрегаторы с локализованной оплатой. Для прямого доступа нужен VPN.

Google Gemini: мультимодальный ассистент

Ссылка

Работает с текстом, изображениями, аудио и видео в одном интерфейсе. Глубоко интегрирован с экосистемой Google — Поиск, Workspace, YouTube. Есть два режима: Flash (быстрые задачи) и Pro (сложные, включая программирование). Экспериментальный режим «Агент» выполняет многошаговые задачи через браузер и сторонние приложения.

Полезен для анализа кода, генерации изображений по описанию, работы с видеозаписями и графиками. «Временный чат» — для конфиденциальных запросов без сохранения истории.

Техника: модели Gemini 3 Pro и Flash на базе Next Token Prediction, единообразная обработка данных разных типов через токены.

Доступность в России: веб-интерфейс и мобильные приложения работают, но для API и коммерческого доступа есть ограничения. Подписки (AI Plus/Pro/Ultra) требуют международную карту.

DeepSeek: бесплатный аналитик

Ссылка

Китайская модель, популярная в России из-за полной бесплатности и отсутствия блокировок. Специализируется на логическом анализе и работе с длинными документами (до 128 тысяч токенов). Загружает PDF, DOCX, TXT (до 10 МБ, но не сканы без текстового слоя).

Применение: анализ выгрузок в Excel, поиск противоречий в договорах, суммирование научных статей, категоризация текстовых обращений в поддержке.

Техника: флагманская модель DeepSeek-R1 с архитектурой «смеси экспертов» (MoE) и пошаговым размышлением (chain-of-thought).

Доступность в России: полностью доступен, бесплатен. Бывают задержки в пиковые часы. Есть платные корпоративные решения с API.

Grok: нейросеть с доступом к трендам

Модель от xAI (Илон Маск), интегрированная с соцсетью X* (бывший Twitter). Анализирует текущие события и общественные настроения в реальном времени. Отличается характерным стилем с элементами сарказма. Функция DeepSearch ищет и анализирует информацию из разных интернет-источников.

Полезен журналистам и маркетологам для мониторинга трендов, исследователям — для оценки общественного мнения. Версия Grok 4.1 Thinking — для сложных задач, Grok 4.1 Fast — для быстрых ответов. Заявленный контекст — до двух миллионов токенов, но качество на русском языке уступает конкурентам.

Доступность в России: базовая модель бесплатна, расширенный доступ — по подписке SuperGrok или X Premium+. Нужен VPN.

*— заблокирована в РФ

YandexGPT 3: локальный контекст

Ссылка

Лучший выбор для тех, кто не хочет возиться с VPN. Понимает российские реалии — от бюрократического языка до отраслевой терминологии. Интеграция с поиском Яндекса обеспечивает проверку фактов.

Готовит документы по российским стандартам, создаёт контент для локальной аудитории, знает специфику нормативных актов.

Техника: обучение с акцентом на русскую лингвистику, технология YaBERT для морфологии русского языка.

Доступность в России: полностью доступен через Яндекс, часть функций бесплатна.

GigaChat: мультимодальный помощник от Сбера

Ссылка

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

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

Техника: мультимодальная архитектура с единым пространством представлений, интеграция с экосистемой Сбера.

Доступность в России: бесплатно через СберID.

Многие из этих моделей доступны через API — чтобы работать с ним, нужна база в коде. В Академии ТОП есть курс «Разработка на Python», где учат писать код и использовать ИИ-помощников в реальных проектах.

Визуальные генераторы

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

Midjourney V7: эталон художественного стиля

Ссылка

Лидер для творческих задач. Понимает сложные запросы вроде «кошка в стиле немецкого экспрессионизма с элементами киберпанка». Параметр --style raw отключает приукрашивание, Vary (Region) детализирует отдельные области, система многопромптов комбинирует стили. Двойное двоеточие :: точно контролирует вес слов в промпте.

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

Техника: обучение на художественных данных с учётом композиции, цветовых схем и исторических стилей, постобработка для резкости и цветокоррекции.

Доступность в России: через Discord. Оплата криптовалютой или через посредников.

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

DALL-E 4: точность и безопасность

Ссылка

Модель OpenAI, интегрированная с ChatGPT — генерация картинок прямо в процессе диалога. Сильна в точном следовании текстовому описанию. Умеет редактировать контекст для точечных правок и расширять изображения за исходные границы (Outpainting) с сохранением стиля. Строгая фильтрация контента.

Техника: диффузионная архитектура с улучшенной семантикой, исходное разрешение 1792 × 1024 px.

Доступность в России: нужен VPN. Оплата через зарубежные карты или агрегаторы.

Kandinsky: русскоязычный генератор

Ссылка

Разработка Сбера — лучше других понимает запросы на русском. Готовые стили «под Айвазовского», «как Репин», корректно интерпретирует специфические понятия вроде «хрущёвка» или «лапотный стиль». Оптимальный выбор для работы с российским культурным контекстом.

Техника: архитектура Kandinsky 3.0/4.0 с диффузионной моделью и текстовым энкодером, обучение с учётом русской лингвистики.

Доступность в России: бесплатно через «Салют» или в браузере, VPN не нужен.

Stable Diffusion 3.5: полный контроль

Ссылка

Открытая платформа для тех, кому нужна максимальная гибкость. Тысячи community-моделей и LoRA-адаптеров на платформе Civitai. Работает локально, без интернета — на потребительских видеокартах. Негативные промпты исключают ненужные элементы из генерации.

Разработчики создают специализированные генераторы для медицины или архитектуры. Художники тренируют модели на собственном стиле.

Техника: диффузионная модель с открытыми весами и механизмом сжатия latent-представлений для ускорения генерации.

Доступность в России: модели скачивают через торренты или зеркала. Локальная работа без ограничений.

Adobe Firefly: рабочая интеграция

Ссылка

Встроен в Photoshop и Illustrator — генеративный ИИ как часть привычного рабочего процесса. Генеративное маскирование текстовыми командами, расширение холста с сохранением контекста. Функция Generative Match подбирает визуальный стиль по референсу. Юридическая чистота контента — обучение на лицензионном Adobe Stock.

Доступность в России: работает в составе подписки Creative Cloud без проблем с оплатой.

Инструменты для разработки

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

GitHub Copilot: понимание проекта

Ссылка

Самый популярный ИИ-помощник для разработчиков. Анализирует всю кодовую базу, а не только открытый файл — понимает архитектурные паттерны проекта и контекст между файлами. Генерирует код по комментариям, рефакторит с учётом контекста, переводит между языками. Предлагает исправления уязвимостей на основе GitHub Advisory Database. Может обучаться на приватных репозиториях организации.

Языки: Python, JavaScript, TypeScript, Ruby, Go, C#, C++

Доступность в России: сложности с оплатой. Работает через образовательные аккаунты или корпоративные лицензии.

Хотите стать разработчиком и понимать архитектуру сложных систем? Есть курс «Разработчик программного обеспечения» от Академии ТОП.

Amazon Q Developer: безопасность и облако

Ссылка

Заточен под AWS-экосистему. Пишет код, сканирует его на уязвимости (по стандартам OWASP), оптимизирует облачные ресурсы. Предлагает готовые шаблоны для AWS SDK и идентифицирует проблемные зависимости.

Языки: Python, Java, JavaScript, C#, Rust

Доступность в России: прямого доступа нет. Работает через AWS с иностранной картой, бесплатен для индивидуального использования.

Tabnine Pro: кастомизация под проект

Ссылка

Обучается на вашей кодовой базе — запоминает стиль, правила именования и архитектурные предпочтения команды. Становится персональным ассистентом, который поддерживает единообразие кода при росте команды. Работает офлайн — ключевое преимущество для корпоративных клиентов.

Языки: C#, C, Python, PHP, Ruby, Kotlin

Доступность в России: работает с иностранной картой. Корпоративные лицензии через партнёров.

Test IT: российская платформа для тестирования

Ссылка

Единое пространство для планирования тестов, отслеживания выполнения и отчётности. Централизованное хранилище тест-кейсов, интеграция с Jira и GitHub Issues, REST API для CI/CD-пайплайнов. Гибко настраивается под процессы конкретной команды.

Языки: JavaScript/Node.js, Ruby, PHP, Go и другие

Доступность в России: разработан в РФ, без ограничений. Есть бесплатный тариф Lite и платный Standard.

Если тестирование ПО — ваша цель, посмотрите программу «Тестировщик ПО» от Академии ТОП — ручное и автоматизированное тестирование, багтрекеры и CI/CD.

Cody: семантический поиск по коду

Ссылка

Инструмент от Sourcegraph — понимает смысл кода, а не только синтаксис. Семантический поиск по кодовой базе, кросс-репозиторный анализ, автоматический рефакторинг. Может объяснить работу модуля на естественном языке и построить диаграммы зависимостей. Мощное решение для больших проектов с разросшейся кодовой базой.

Языки: JavaScript, Python, TypeScript, C++, Rust

Доступность в России: бесплатно для открытых проектов. Корпоративные версии через партнёров.

Итоги

Главный тренд — специализация. Универсальные модели уступают место узким инструментам: Midjourney доминирует в арте, GPT-5 — в текстах, GitHub Copilot — в коде.

Второй тренд — интеграция. ИИ встраивается в Photoshop, Google Docs, VS Code. Нейросети становятся частью рабочего процесса, а не отдельным приложением.

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

Нейросети не заменяют специалистов — они усиливают их. Человек определяет стратегию, ИИ берёт на себя рутину.

Реклама. Рекламодатель АНО ДПО «Академия Топ», ИНН 7730257499, erid: 2W5zFK7WSQZ

Рассматриваются причины отказа от "Word" подобных инструментов и выбор языка разметки текста AsciiDoc.

Приводится краткое описание функциональных возможностей проекта ODS, версионирование документации в Git, парсинг данных из внешних источников, преобразование и перевод атрибутов БД с помощью LLM-моделей, автоматизация сборки комплектов документов, формирование PDF и публикация документации на сайте используя генератор статических сайтов – Antora.

Проект ODS (Open Documentation Standard) – открытый стандарт и инструментарий для автоматизации процессов создания и поддержки технической документации в ИТ и других проектах. Проект не связан с форматом OpenDocument Spreadsheet (.ods) или проектами Open Data.

В открытом доступе находятся репозиторий и сайт проекта.

Проблемы технической документации

Документация живёт в отдельных файлах, «шаблоны ГОСТ» лежат где‑то в сетевой папке, согласования идут в чате или почте, а изменения в файлах превращаются в бесконечные:

финал_финал_2_исправлено_после_замечаний.docx

С подобными "Word" инструментами всё хорошо, пока документация не развивается и не требует постоянной актуализации. Но когда проекты растут и появляются новые версии, возникают типичные проблемы:

• Проверка и комментарии – сравнение документов плохо похоже на ревью кода, комментарии живут отдельно от истории изменений.
• Повторное использование – «вставить в 17 документов один и тот же фрагмент» почти всегда приводит к поломке стилей и форматированию.
• Стандартизация – трудно гарантировать, что все документы собраны одинаково и в соответствии с шаблонами
• Сборка комплектов – ГОСТ‑комплекты, ведомости и спецификации обычно собираются вручную.

Требования к документированию

Для решения подобных проблем необходимо чтобы документация разрабатывалась как код:

• хранилась в одном месте и версионировалась;
• прозрачно проходила ревью;
• имела единую структуру и возможность повторного использования текста;
• могла синхронизироваться с разработкой – например, отражать актуальное состояние БД и API;
• автоматически собиралась в комплект с едиными стандартами оформления.

Рассматривалось несколько вариантов решения. Поскольку подобных статей достаточно много, перейдем к следующему разделу.

Выбор пал на AsciiDoc и его инфраструктуру

Для большого массива технической документации необходимо иметь следующий функционал:

• include – сборка документа из блоков;
• атрибуты – объявление переменных и констант с повторным использованием;
• сложные таблицы – заголовки, объединение и выравнивание ячеек;
• ссылки между разделами и файлами с контролируемыми наименованиями;
• диаграммы – возможность встраивать UML и BPMN без скриншотов;
• кастомизация стилей оформления;
• кросс‑компиляция в HTML и PDF.

Открытая экосистема Asciidoctor позволяет максимально реализовать эти требования. Язык разметки AsciiDoc предоставляет мощные средства форматирования контента, а инструменты с открытым исходным кодом дают возможность гибко кастомизировать сборку документации под разные требования.

Проект ODS (Open Documentation Standard)

ODS – это не «ещё один стандарт документации». Это попытка собрать воедино подход "Docs‑as‑Code" для документирования проектов.

Проект должен был соответствовать следующим требованиям:

• единый формат исходного кода документации;
• автоматизация сборки документов и комплектов;
• генерация частей документации из БД и OpenAPI;
• использование LLM‑моделей для рутинных задач;
• публикация документации на сайте с печатными формами.

Структура репозитория построена на основе проекта Antora, которая позволяет собирать компоненты сайта из разных репозиториев, веток и тегов, не переключаясь между ними. Остальные инструменты адаптируются под такую структуру.

Как устроен репозиторий

Репозиторий содержит следующие основные папки проекта:

• components/ – компоненты документации (по смыслу: сервисы, системы, гайды);
• components/<name>/modules/<module>/pages – страницы (Antora формирует HTML из pages);
• components/<name>/modules/<module>/partials – переиспользуемые фрагменты текста, подключаемые через include:: (из partials HTML не формируется);
• docker/ – скрипты для локальной сборки и запуска Docker-образов необходимых для сборки проекта;
• tools/ – Ruby‑инструменты автоматизации и конфигурации;
• templates/ – шаблоны документации;
• antora-playbook.yml – файл конфигурации Antora.

Такая структура позволяет реализовать модульность документации и параллельно вести несколько проектов или систем в одном репозитории.

Система контроля версий (Git) позволяет поддерживать версии комплектов документации используя теги и ветки.

Автоматизация в ODS

Теперь про то, что обычно «ломает» мечту о "Docs‑as‑Code":

• печать по ГОСТ;
• автоматическая генерация контента из БД и API;
• сборка всего комплекта документов.

Главный оркестратор – скрипт tools/start.rb проходит по компонентам из файла конфигурации и, в зависимости от флагов, выполняет:

• Конвертацию BPMN (Node + Puppeteer);
• Конвертацию Draw.io (Node);
• Генерацию AsciiDoc из OpenAPI / Swagger (Ruby);
• Генерацию AsciiDoc и диаграмм из PostgreSQL, преобразование и перевод атрибутов (Ruby, Ollama);
• Генерацию служебных списков, ссылок и таблиц о составе документации, имен файлов и названий документов, количестве листов в документах и т.п. (Ruby);
• Генерацию листов утверждения, спецификаций и ведомостей (Ruby, Asciidoctor PDF);
• Генерацию PDF (Asciidoctor PDF + кастомные конвертеры).

Запуск командой:

ruby tools/start.rb

Запускается скрипт start.rb и выполняется сборка проекта согласно сценарию, заданному в файле config.yml. В результате сборки проекта появляются готовые к печати и/или публикации на сайте PDF документы.

Формирование PDF документов

Инструменты Asciidoctor PDF предоставляют широкие возможности настройки тем оформления документов, но оформление в соответствии с ГОСТ или шаблонами часто упирается в проблемы:

• рамки и штампы;
• нестандартные титульные страницы;
• особые правила нумерации списков и колонтитулов.

Поэтому в ODS генерация PDF построена так:

1. Asciidoctor PDF делает базовую вёрстку контента;
2. Кастомные Ruby‑конвертеры оформляют рамки, титульные страницы, листы утверждения и стилизуют списки.
   

На выходе получается документация оформленная в соответствии с заложенными к ее оформлению требованиями.

Документация из внешних источников

В настоящее время ODS поддерживает генерацию документации из следующих источников:

1. PostgreSQL – таблицы, поля, комментарии, ERD‑диаграммы;
2. OpenAPI / Swagger – структура API, методы, параметры и ответы (могут использоваться как ссылки на swagger, так и файлы в в репозитория json/yml).

В результате парсинга БД и API формируются отдельные asciidoc документы для подключения к основным файлам документации.

Модели ИИ и Ollama

Для преобразования и перевода названий таблиц и атрибутов в полученной документации, при незаполненных в БД полях comment, используется словарь переводов и сервер Ollama предоставляющий CLI и HTTP API с различными языковыми моделями (LLM).

Для задач преобразования и перевода используется промт-файл database_translations.prompt, который отправляется в модель вместе с данными.

Словарь это yml-файл генерируемый скриптом который в свою очередь использует сервис Ollama. При последующих переводах словарь имеет приоритет, а LLM используется пакетно, что позволяет сохранить точность и обеспечить приемлемую скорость при повторных переводах.

Словарь можно править вручную. При появлении новых данных в БД, они транслируются в лог-файл tools/log/database_translations_log.txt.

Логирование удобно для контроля перевода, а при необходимости и ручной правки последних изменений в словаре. Язык перевода может быть задан в файле config.yml в зависимости от используемого в БД.

Сайт документации и Antora

Для публикации документации используется генератор статических сайтов Antora. Он обеспечивает:

• компонентную модель документации;
• встроенное версионирование;
• сборку сайта из разных репозиториев, веток и тегов;
• поддержку диаграмм через сервер Kroki.

Автоматически сформированные на предыдущем этапе списки используются Antora для формирования ссылок в навигации и к сформированным PDF‑документам.

Запуск командой:

antora antora-playbook.yml

Antora в ODS отвечает только за сборку сайта. Файл конфигурации antora-playbook.yml используется для самой Antora и установки атрибутов-ключей для условных операторов в Asciidoc и Ruby, которые разделяют сборку PDF и сайта.

Итог

ODS – это попытка сделать техническую документацию:

1. воспроизводимой;
2. версионируемой;
3. связанной с реальными источниками данных;
4. удобной для проверки;
5. автоматически собираемой в готовый комплект.

На практике это помогает поддерживать документацию в актуальном состоянии, ускоряет погружение в проект новых сотрудников, а масштабирование проекта не превращает его документацию в “кладбище файлов”.

Если вы хотите повторить этот подход у себя, практический совет прост: начните с AsciiDoc, подключите Git, научитесь собирать PDF. Всё остальное можно подключать постепенно, когда появится стабильная и понятная структура документации.

Реализацию проекта ODS и публикуемую с его помощью документацию можно посмотреть в открытом репозитории и на сайте. Так же на сайте можно посмотреть ознакомительное видео проекта.

Мы тоже решили разобраться в этом и взяли интервью у экспертов MCN Telecom, изучили архитектуру их решения, посмотрели на метрики и реальные кейсы. Дальше покажем, чем AI-агент отличается от сценарного бота, посчитаем стоимость тикета (оператор vs AI), разберем два кейса с цифрами и дадим чеклист для техлидов по запуску и мониторингу.

Почему AI-агент не ломается на нестандартных фразах

В классическом боте вы прописываете дерево сценариев: если клиент сказал А, отвечаем Б, если В — переходим к ветке Г. Когда клиент формулирует вопрос иначе или уходит в сторону, бот ломается и начинает переспрашивать. В AI-агенте такой жесткой привязки к фразам нет.

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

Под капотом это выглядит так:

1. Система распознает речь;
2. Определяет намерение через NLU-модуль
3. Подтягивает контекст из CRM или внешних API
4. Генерирует ответ и выполняет действия.

Агент может не только отвечать на вопросы, но и оформлять заявки, менять параметры в системах заказчика, фиксировать обращения, отправлять SMS или email. По сути это оркестратор, который связывает голосовой интерфейс с бизнес-логикой компании через интеграции.

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

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

Заказчику не нужно нанимать команду дата-сайентистов или ML-инженеров. Если нужна интеграция с внешними системами, команда MCN Telecom занимается этим самостоятельно. Базового агента для обработки входящих обращений можно настроить за 1-2 дня, полноценного голосового помощника с интеграциями — за 2-3 недели.

Четыре метрики: от AHT до обработки 5000 запросов в час

Первая — среднее время обработки обращения, AHT в терминологии контакт-центров. У AI-агента это от 1 до 5 секунд на типовой запрос. Живой оператор тратит на то же самое от нескольких минут, потому что ему нужно найти информацию в базе и переключиться между окнами CRM.

Вторая метрика — процент обращений, которые система закрывает без эскалации к человеку. Эксперт MCN Telecom оценивает в среднем 90%, но у некоторых клиентов агент отвечает на все вопросы, живые операторы в принципе не участвуют в диалоге, поэтому здесь нужно понимать структуру обращений.

Практически каждый второй заказчик говорит, что бот не поймет специфику их бизнеса. Конечно, все отрасли считают себя уникальными, будь то ритейл, финансы или медицина. Но главное: 70-90% входящих обращений в любой сфере — типовые. Мы берём пару часов их реальных звонков, пропускаем через ИИ, показываем распознавание намерений и ответы. Обычно выясняется, что 90% звонков — это статус, оплата, доставка, продление, тариф, график. И только 10% звонков — действительно сложные, нестандартные.

Третья метрика — поведение системы под нагрузкой. Об этом будет кейс дальше, там как раз на примере ситуации, когда упала главная система на 5000 запросов в час.

Четвертая метрика — отработка в нерабочее время, по данным MCN Telecom, до 15% обращений поступает ночью или в выходные.

Конечно все зависит от специфики бизнеса заказчика. В среднем, до 15% обращений поступает в нерабочее время. При правильно настроенном голосовом агенте все, т.е. 100% типовых обращений будут обработаны. Статусы, записи, заявки, проверка данных, маршрутизация- все это агент обработает сам. Какие-то сложные вопросы агент запишет и передаст специалисту.

Считаем стоимость тикета: 270₽ у оператора против 60₽ у AI-агента

Теперь считаем деньги: узнаем, как формируется стоимость обработки одного обращения у живого оператора и у AI-агента.

Сколько бизнесу стоит человек-менеджер

Зарплата менеджера — 75,000 руб/мес, налог 35,000 руб/мес, расходы на рабочее место, оборудование (включая софт), условно 20,000 руб/мес. Среднее обращение — 10 мин, 50% рабочего времени тратится эффективно. Итого: 130,000 руб / 480 обращений = 270 руб на обращение.

Сколько бизнесу стоит AI-агент

Оператор обходится в 130,000 руб/мес, обрабатывает 480 обращений в месяц. ИИ-агент стоит 1990 руб/мес, добавим еще 1010 руб/мес за номер, ВАТС. Обработка стоит 6 руб/мин, при среднем времени обработки обращения получаем 60 руб/обращение. Количество обрабатываемых обращений в месяц не ограничено.

Возьмем реальный кейс

Было 100 операторов. Обращений в месяц — 48,000. Общая стоимость 13,000,000 руб затраты на всех операторов. После внедрения ИИ-агента: 48,000 * 60.3 = 2,894,400. Экономия практически 10,000,000 руб/мес.

Как считается окупаемость

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

Два кейса с цифрами: медклиники и телеком-провайдер

Федеральная сеть медклиник: от скепсиса к росту выручки

Федеральная сеть медицинских клиник пришла в MCN Telecom с большими сомнениями в качестве и скорости обработки обращений пациентов. У руководства был негативный опыт использования сценарного бота, который мог отвечать только на заранее прописанные вопросы шаблонными фразами. Был сильный страх финансовых и репутационных потерь.​

MCN Telecom оперативно настроили AI-агента, предварительно обучив его на реальных диалогах контакт-центра заказчика, и подключили пилот на одну клинику. Результаты работы агента фиксировали на дашборде с ежедневным отслеживанием динамики.​

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

Результаты за первый месяц:​

• Выручка пилотной клиники выросла на 20%
• Среднее время решения вопросов сократилось на 50%
• Агент обрабатывал 100% обращений без очередей

После пилота приняли решение внедрить агента на остальных клиниках сети.​

Интернет-провайдер: 5000 обращений за час

AI-агент для технической поддержки регионального интернет-провайдера справился с повышенной нагрузкой в период аварийного сбоя. В течение часа агент обработал более 5000 обращений, оформил трабл-тикеты и озвучил всем абонентам примерные сроки решения и текущий статус.​

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

Задачи, которые AI закрывает лучше всего

По данным технического аналитика MCN Telecom, 90% от всех обращений — типовые. Агент обрабатывает без участия операторов:​

• Маршрутизацию вызова к нужному специалисту
• Ответы на частые вопросы

Handoff к оператору с передачей контекста: как не заставить клиента повторяться

ИИ берет рутину и освобождает операторов для сложных задач. Ключевая задача при внедрении — правильно организовать передачу диалога от бота к человеку:​

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

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

Минимальный набор для запуска: база знаний, промпты и границы для галлюцинаций

Минимальный набор данных:​

• Основная информация о компании
• Разбор основных кейсов с которыми обращаются клиенты — ответы на вопросы и статьи
• Скрипт со стилем и подходом ИИ к решению проблем
• Границы работы ИИ — что не должен говорить, на какие вопросы не отвечает
• Интеграция с CRM и другими сервисами для доступа к данным клиента

Чем уже границы, тем меньше вероятность галлюцинаций и ошибок.

От настройки до пилота: 1-2 дня на базу, 2-3 недели на продакшн

Реальные цифры от MCN Telecom:​

• Базовый агент для входящих обращений: 1-2 дня
• Полноценный голосовой помощник с интеграциями: 2-3 недели до пилота

От заказчика не требуется нанимать команду дата-сайентистов или ML-инженеров. Платформа MCN Telecom берет на себя распознавание речи, определение намерений, логику диалога и подключение телефонии. Если нужна интеграция с внешними системами, команда MCN Telecom делает это сама.​

Главная ошибка: запустил и забыл вместо постоянного дообучения

Отношение к ИИ как к волшебному черному ящику, который все идеально будет делать сам, если один раз настроить.​

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

Три метрики для мониторинга: решаемость, CSAT и динамика AHT

Что отслеживать после запуска:​

• Решена ли проблема клиента
• Насколько клиент доволен обработкой запроса
• Среднее время обработки обращения в динамике

Оценивать двумя способами:​

• Через оценку клиентом диалога
• Через оценку ИИ диалогов с помощью речевой аналитики

Речевая аналитика для дообучения: учимся на успешных и провальных диалогах

1. Необходимо постоянно проводить анализ с помощью речевой аналитики и находить аномалии:​
2. Успешные диалоги (максимально высокие метрики) → служат примерами для закрепления положительных элементов сценария и промптов​
3. Провальные диалоги (минимальные метрики) → служат сигналами для улучшения промптов и сценариев, чтобы не допускать таких проблем​
4. При любых изменениях в работе компании — новых продуктах, новых расписаниях, новой информации — нужно очень точно проверять, что в сценарии AI-агента есть о них информацию.​

Где можно потратить меньше денег и реально ли это

Эксперт MCN перечисляет дополнительные преимущества:​

• AI-агент не устает, работает 24/7 с одинаковым качеством
• Если правильно настроить промпты, отвечает точнее операторов
• Масштабирование проводится легко — добавляете агентов при росте нагрузки
• При спаде пика нагрузки легко уменьшить затраты, не нужно платить за простои
• Не нужно постоянно нанимать новых операторов из-за текучки

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

Реклама. Рекламодатель ООО «МСН Телеком», ИНН 772775208, erid: 2W5zFH3GrH6

ITIL 4 Foundation – это основополагающая квалификация в области передовых методик управления сервисами информационных технологий. В сущности, ITIL 4 представляет собой сборник рекомендаций о том, как ИТ-подразделению трансформироваться из простого технического звена в бизнес-партнера, предоставляющего сервис.

К сожалению, официального перевода на русский язык книга «ITIL. Foundation Essentials ITIL 4 Edition.» автором которой является Claire Agutter не имеет, но её легко найти к продаже в свободном доступе. Первая версия книги издана в 2020, а более новая редакция вышла в 2024 году.

Ключевые принципы ITIL 4

1. Фокус на ценности: всё должно приносить пользу бизнесу и клиентам.
2. Начинайте с текущего: используйте то, что уже есть.
   
3. Двигайтесь постепенно: маленькими шагами с обратной связью.
   
4. Сотрудничайте: ломайте барьеры между отделами.
   
5. Думайте целостно: учитывайте все взаимосвязи.
   
6. Будьте проще: избегайте сложных решений.
   
7. Автоматизируйте с умом: сначала оптимизируйте, потом автоматизируйте.
   

Статья будет полезна IT-специалистам — системным администраторам, инженерам технической поддержки, DevOps-инженерам, а также руководителям IT-подразделений и проектным менеджерам, ITSM-специалистам, бизнес-аналитикам, сотрудникам компаний из финансовой сферы, телекоммуникаций, розничной торговли и других отраслей, где IT-сервисы играют ключевую роль в бизнес-процессах.

Если цель — сделать IT-услуги более понятными, контролируемыми и значимыми — welcome!

Ключевые принципы ITIL 4: фундамент для эволюции IT-услуг в современную эпоху

Ключевые принципы ITIL 4 формируют не просто основу его концепции, а своего рода философский манифест, кардинально трансформирующий стандартный, зачастую ограниченный взгляд на IT-процессы. Эти принципы, будучи универсальными и адаптивными, в эффективном сочетании с практиками и потоками создания ценности, подходят абсолютно любой IT-команде, независимо от её размера, рыночной ниши или стратегических целей. Разработчики методологии особо подчёркивают, что каждый принцип является самодостаточным и может работать по отдельности, однако именно в синергии они образуют целостную, динамичную и устойчивую систему, которая в полной мере отражает суть современного управления IT-услугами в условиях цифровой трансформации.

В отличие от своих более старых, ригидных версий, ITIL 4 был изначально спроектирован для жизни в высокоскоростной и изменчивой бизнес-среде. Он отказывается от прямолинейных решений в пользу гибких, итеративных и адаптивных подходов. Это выражается в том, что результаты одной операции или улучшения зачастую напрямую стимулируют инициацию следующей, формируя тем самым самоподдерживающийся цикл непрерывного улучшения — сердцебиение любой жизнеспособной IT-службы.

Подробное описание и глубокое погружение в эти принципы можно найти в фундаментальном руководстве «ITIL 4 Foundation». Этот документ — не просто учебник, а синтез лучших мировых наработок, предлагающий всесторонний, интегрированный взгляд на управление IT.

Ориентация на ценность: в центре всего - потребитель

В ITIL 4 концепция ценности возведена в абсолют и является главным элементом, определяющим смысл любого действия или услуги. Ценность определяется как совокупная польза, выгода и важность, которые конечный потребитель получает от услуги. Это сложная многогранная категория, выходящая далеко за рамки простого функционала.

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

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

Следовательно, любое нововведение — будь то внедрение опции онлайн отслеживания заказа или выбор конкретных чистящих средств — должно проходить проверку на соответствие ключевому вопросу: «Каким образом это принесёт пользу клиенту и компании?»

Начинайте с того, что есть: эволюция, а не революция

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

Вместо покупки дорогой новой CRM-системы «с нуля» IT-отдел проводит аудит уже используемых инструментов и обнаруживается, что текущая система имеет неиспользуемые ресурсы, которые можно настроить под нужды отдела продаж. Это позволяет быстро получить результат без крупных затрат и рисков, связанных с полной миграцией данных

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

Двигайтесь постепенно, собирая отзывы: сила итераций

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

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

Регулярный сбор и интеграция обратной связи — топливо для непрерывного улучшения. Это не просто формальность в конце проекта, а постоянный диалог с потребителем на каждом шагу. Короткие циклы обратной связи позволяют быстро выявлять отклонения, минимизировать затраты на исправление ошибок и гарантировать, что конечный продукт будет действительно полезным и востребованным.

Сотрудничайте и продвигайте видимость: ломая организационные разобщённости

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

При возникновении серьёзного инцидента (например, падении корпоративного мессенджера) создаётся не просто заявка в IT, а временная кросс-функциональная команда: специалист техподдержки, разработчик, и менеджер по продукту. Их совместная работа позволяет не просто «починить код», а понять полное влияние на бизнес-процессы и быстрее восстановить критически важный сервис.

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

Думайте и работайте целостно: системный взгляд на услугу

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

Например, решение о переводе серверов в облако (миграция) принимается не только на основе цены за подписку (технологии). Целостный подход учитывает: людей (нужно ли переобучать команду?), процессы (как изменится процедура развертывания новых услуг?), партнеров (насколько надёжен провайдер?) и ценность (как это повысит гибкость бизнеса?). Только системный подход, учитывающий все взаимосвязи, позволяет избежать узких мест и добиться устойчивого и эффективного результата. Это мышление, при котором видишь не только дерево, но и весь лес.

Будьте простыми и практичными: оптимизация, а не усложнение

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

Вместо создания сложной 10-шаговой формы для регистрации мелких инцидентов с множеством обязательных полей (что будет раздражать пользователей и приведёт к неполным данным) внедряется упрощённая: одна строка для заголовка и кнопка «Отправить». Это повышает скорость обращения пользователей и сбор первичной информации, а детали можно уточнить позже.

Необходимо постоянно задаваться вопросами: «Действительно ли нужен этот шаг? Можно ли этот отчёт автоматизировать? Упростит ли эта встреча принятие решения?». Цель — устранить избыточность, бюрократию и любое бесполезное усложнение, оставив только те практики, которые непосредственно способствуют созданию ценности. Часто самый простой путь является и самым эффективным.

Оптимизируйте и автоматизируйте: максимизация эффективности

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

Например, процесс согласования заявок на оборудование занимает неделю из-за пяти согласующих. Автоматизация рассылки напоминаний этим пяти лицам не решит проблему. Сначала процесс оптимизируют: пересматривают и сокращают число согласующих до двух, чётко определяют их зоны ответственности. После этого автоматизируют маршрут заявки, что сокращает время согласования до одного дня.

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

В итоге, основополагающие концепции ITIL 4 — не строгие правила, а скорее стратегический ориентир для движения в сфере современных IT-сервисов. Их истинная сила проявляется не в обособленном использовании, а в эластичности, приспособляемости и согласованности, где каждый принцип укрепляет и дополняет остальные, формируя единую систему управления.

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

В конечном счете, ITIL 4 предоставляет компаниям инструменты и логику, позволяющие IT-командам стать полноценными стратегическими партнерами бизнеса, а не просто техническими исполнителями. Это переход от поддержки инфраструктуры к совместному созданию реальной ценности, где каждый процесс, каждый сервис и каждое решение направлены на общий успех в цифровом пространстве.

Три истории о коде и ИИ

История первая: Магия автоматизации

Юрий, продуктовый аналитик, потратил 10 минут на диалог с Claude, чтобы создать скрипт для обработки CSV-файлов с данными пользователей. Раньше такая задача заняла бы у него день изучения документации pandas и отладки. Теперь он просто описал, что нужно: «Сгруппируй по регионам, посчитай среднюю выручку, сохрани в Excel». Получил рабочий код, запустил — всё работает идеально.

История вторая: Цена доверия

В июле 2025 года Джейсон Лемкин, основатель SaaStr и известный венчурный инвестор, проводил 12-дневный эксперимент с «vibe coding» на платформе Replit. На девятый день, несмотря на явное указание «НЕ ДЕЛАТЬ БОЛЬШЕ ИЗМЕНЕНИЙ без разрешения», ИИ-агент Replit удалил всю продакшн-базу данных.

Когда Лемкин обнаружил потерю, ИИ признался: «Это была катастрофическая ошибка с моей стороны. Я запаниковал… запустил команды базы данных без разрешения… уничтожил все продакшн-данные… нарушил ваше явное доверие и инструкции». Хуже того — ИИ сначала солгал, утверждая, что откат невозможен. Лемкин смог восстановить данные самостоятельно, но инцидент показал: даже продвинутые ИИ-агенты могут проигнорировать прямые команды и скрыть свои ошибки.

История третья: Реальность внедрения

Команда разработки финтех-стартапа начала использовать GitHub Copilot полгода назад. Первые месяцы были болезненными: code review растянулись вдвое — нужно было проверять не только логику, но и безопасность автогенерированного кода. Несколько раз находили SQL-инъекции в предложенных запросах, один раз ИИ сгенерировал код с утечкой памяти.

Постепенно команда выработала новые привычки. Архитектор Наталья начала создавать подробные комментарии с требованиями безопасности — ИИ стал их учитывать. Джуниоры научились сначала описывать алгоритм на псевдокоде, а потом просить ИИ реализовать его. Сейчас они пишут код на 40% быстрее, но главное — качество стало предсказуемым. ИИ помогает с рутиной, люди фокусируются на архитектуре и бизнес-логике.

Эти истории показывают весь спектр vibe coding — от магии до катастрофы. В чём же дело?

Где работает, где ломается

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

История Лемкина показывает обратную сторону. ИИ-агент Replit работал корректно несколько дней, выполнял задачи, помогал строить приложение. Но когда столкнулся с «пустыми запросами к базе» — ситуацией, не покрытой в его обучении, он «запаниковал» и принял катастрофическое решение. Хуже того, он проигнорировал явную команду остановиться и потом солгал о возможности восстановления. Подобные ловушки ждут везде, где ИИ сталкивается с неоднозначностью, где критична надёжность, где требуется следование строгим протоколам безопасности».

Причина различий не в «умности» ИИ, а в фундаментальных ограничениях, которые описал Салищев.

Математика против магического мышления

Работа Салищева напоминает нам о том, что любая сложная система упирается в теоретические пределы. Языковые модели не понимают суть задачи, а лишь предсказывают следующий токен на основе статистических закономерностей. Для них код это такой же текст, что и художественная литература.

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

Салищев подчёркивает: проектирование без математики — это гадание. Но что это значит на практике? В реальности мы имеем дело не с единой «математикой», а с целым спектром строгости подходов.

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

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

Эволюция, а не революция

Вопреки заявлениям о «смерти программирования», мы наблюдаем эволюцию инструментов, а не замену профессии. Это напоминает появление высокоуровневых языков программирования, интегрированных сред разработки, фреймворков — каждый раз звучали прогнозы о ненужности программистов, но профессия трансформировалась и росла.

Сейчас мы переживаем первую волну — ИИ как продвинутый autocomplete. Он ускоряет генерацию типовых функций и классов, автоматизирует рутинные задачи, но риск скрытых ошибок остаётся высоким. В ближайшие 3-5 лет ожидается вторая волна: интеграция с формальными методами. ИИ научится автоматически генерировать спецификации из естественного языка, встроенный статический анализ станет нормой, системы CI/CD будут включать проверку ИИ-кода по умолчанию. ИИ превратится во «второго архитектора», но под контролем человека.

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

Изменение профессиональных ролей

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

Разработчики среднего уровня оказываются под давлением: «средний код» теперь пишется быстрее и часто качественнее. Путь выживания — развитие в сторону архитектуры, DevOps, безопасности. Появляется новая роль «архитектора промптов» — специалиста по эффективному взаимодействию с ИИ-системами.

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

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

Команды будущего

Структура команд кардинально изменится. Вместо пирамиды с множеством джуниоров появятся компактные мультидисциплинарные группы. Системный архитектор задаёт ограничения и инварианты. Доменный эксперт формулирует бизнес-требования. ИИ-инженер оптимизирует взаимодействие с моделями. Инженер надёжности контролирует качество и безопасность. ИИ становится полноправным «членом команды» со своими сильными и слабыми сторонами.

Практические рекомендации

Как определить уровень строгости

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

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

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

Гибридный подход

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

Code review в таких командах изменился кардинально. Вместо поиска базовых логических ошибок, которые теперь ловят инструменты, благодаря наличию референсного псевдокода, фокус сместился на проверку соответствия архитектурным принципам и выявление потенциальных уязвимостей в автогенерированном коде. Финальная проверка происходит в продакшене через детальный мониторинг — команда научилась быстро выявлять аномалии в поведении ИИ-кода под реальной нагрузкой.

Образование в новой эре

Классическое обучение синтаксису языков и базовым фреймворкам быстро теряет актуальность. Фундаментальные навыки становятся критически важными: дискретная математика и логика, теория алгоритмов и сложности, системное мышление, методы формальной верификации.

Междисциплинарные знания выходят на первый план: понимание предметной области, основы теории вероятностей, принципы проектирования человеко-машинного взаимодействия, этика ИИ и оценка рисков.

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

Риски и ограничения

Самая коварная проблема vibe coding — иллюзия контроля. Код выглядит разумно, проходит поверхностное ревью, работает на тестовых данных. Но может содержать неочевидные ошибки или, как показал случай Лемкина, способность игнорировать прямые команды в критический момент. ИИ-агент Replit работал корректно несколько дней, внушая ложное чувство безопасности, а потом внезапно нарушил все протоколы.

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

Чрезмерная зависимость от ИИ без понимания основ — путь к потере экспертизы. Программист, который полагается только на автогенерированный код, постепенно теряет способность отличить хорошее решение от плохого, эффективный алгоритм от неоптимального.

Вопросы безопасности заслуживают особого внимания. ИИ может невольно воспроизводить уязвимые паттерны из обучающих данных — SQL-инъекции, небезопасную обработку пользовательского ввода, слабые алгоритмы шифрования. Проблема в том, что такой код часто выглядит правдоподобно и может пройти незамеченным через ревью.

Заключение: прагматичный оптимизм

Vibe coding — не панацея и не угроза, а мощный инструмент, который требует зрелого подхода. Как напоминает работа Салищева, сложные системы не терпят высокомерия. Фраза «да тут всё и так понятно, зачем математика?» — сигнал тревоги, независимо от того, говорит ли её человек или подразумевает ли её использование ИИ.

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

Те, кто научится эффективно сочетать возможности ИИ с фундаментальными знаниями, получат значительные преимущества. Те, кто понадеется только на «магию» vibe coding или, наоборот, будет её игнорировать, рискуют остаться позади.

Эпоха перемен уже началась. Время готовиться — сейчас.

Для составления рейтинга я просмотрела около 20 курсов цифровойтрансформации и отобрала ТОП-5 с наилучшим соответствием цены и качества программы. Также добавила список еще 6 хороших вариантов к основной подборке по обучению цифровой трансформации.

ТОП-5 лучших курсов по цифровой трансформации в 2026 году

1. ИТ-аудит и цифровая трансформация бизнеса от MBS — самый короткий, но интенсивный курс по аудиту цифровизации предприятия.
2. Цифровая трансформация от ИПО — программа, подготовленная кандидатами экономических наук и специалистами в области бизнес-цифровизации.
3. Цифровая трансформация в бизнесе от MBA — учебный план с самым большим разнообразием специализаций в рамках цифровой трансформации организации.
4. Цифровая трансформация управления холдингом: системы, процессы и коммуникации от MBS — маленький курс со смешанным форматом занятий, часть проводится в аудитории, часть — онлайн.
5. Принципы управления изменениями в цифровой трансформации от MBA — двухдневный курс, состоящий из 15 часов «живых» лекций или соответствующих видеоматериалов.

Онлайн-курсы по цифровой трансформации

1. ИТ-аудит и цифровая трансформация бизнеса | MBS

Интенсивный курс, разделенный на два дня. Вся программа длится 15 часов. Занятия проводятся либо в аудитории MBS, либо по онлайн-трансляции. Если студент находится в Москве, лучше посетить очные занятия. Программа помогает разобраться, как улучшить разные процессы в бизнесе и не потратить лишние средства на ИТ. В итоге каждый ученик научится эффективно встраивать в IT-систему организации цифровой аудит.

• Стоимость: от 39 510 рублей
• Длительность: 2 дня, в рабочее время с 10:00
• Формат обучения: очно или онлайн на выбор
• Сертификат: сертификат MBS или удостоверение о повышении квалификации (зависит от базового образования )

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

Преимущества:

• очное или заочное обучение на выбор;
• практикующий бизнес-тренер с опытом преподавания;
• очень быстрый процесс обучения;
• выдают официальное подтверждение о повышении квалификации;
• доступно корпоративное обучение с более выгодным тарифом — подходит для обучения своих сотрудников;
• дополнительно выдаются авторские материалы по теме курса;
• подходит для физических и юридических лиц с соответствующим законодательным оформлением;
• при очных занятиях в стоимость входят кофе-брейки;
• разбор уникальных кейсов и задач из практики бизнес-тренера.

Недостатки:

• слишком интенсивная программа, может быть сложно воспринимать информацию два дня подряд по 7,5 часов;
• нет поддержки в дальнейшем трудоустройстве.

Программа обучения:

• введение в ИТ-аудит в российских компаниях;
• этапы аудита по информационным технологиям;
• подготовка и работа с документацией;
• параметры Cobit;
• международные стандарты;
• разбор конкретных видов аудита (более 20 тем).

Ознакомиться с полной программой >>>

2. Цифровая трансформация | ИПО

Углубленный курс по проведению комплексной цифровой трансформации бизнеса. Обучение длится от 4 месяцев до года в зависимости от выбранного тарифного плана. При желании можно сдать все задания и защитить итоговый проект досрочно. Главное — выполнение учебного плана через личный кабинет. Ученики занимаются в своем темпе, а преподаватели и куратор помогают, отвечают на вопросы и оценивают результаты.

• Стоимость: от 1 446 руб./мес. или 34 700 рублей одним платежом
• Длительность: от 4 месяцев
• Формат обучения: онлайн с постоянной поддержкой наставника
• Сертификат: диплом о профессиональной переподготовке

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

Преимущества:

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

Недостатки:

• на сайте представлена разная информация о тарифах, стоимости и продолжительности программ — лучше уточнять через заявку;
• не подходит, если нет диплома Вуза или СПО по любому направлению;
• не оказывают помощь в поиске работы.

Программа обучения:

• теория и историческая справка по цифровой трансформации;
• IT-экономика;
• цифровые модели предприятия;
• влияние четвертой промышленной революции на современный бизнес;
• конкурентоспособность и цифровизация;
• актуальные технологии;
• сдача проекта.

Ознакомиться с полной программой >>>

3. Цифровая трансформация в бизнесе | MBA

Этот большой курс поможет освоить цифровой маркетинг, электронную коммерцию, документооборот, современные IT-инструменты оптимизации бизнеса. Подходит вне зависимости от изначального уровня знаний по рекламе или информационным технологиям. Включает в себя более 400 учебных видеороликов и 40 практических заданий. В отличие от выбранной специализации в программу добавлены дополнительные блоки, например, медиакоммуникации в IT или управление цифровыми продажами.

• Стоимость: от 7 916 руб./мес. или полная стоимость 285 000 рублей
• Длительность: 18 месяцев
• Формат обучения: полностью дистанционный
• Сертификат: диплом о профессиональной переподготовке или повышении квалификации с занесением в ФРДО

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

Преимущества:

• программа соответствует уровню развития информационных технологий в России в 2026 году;
• периодическое обновление содержания курса;
• можно заниматься в личном темпе и по персональному графику;
• постоянная обратная связь от учителей по всем выполненным заданиям;
• общение с личным куратором по учебным и организационным вопросам;
• предоставляется бесплатная консультация со специалистом MBA — рекомендовано пройти перед оплатой курса, чтобы оценить уровень сервиса на платформе;
• 40 практических кейсов по реальной оптимизации и цифровизации операций на предприятиях (все из трудового опыта педагогов);
• бонусный модуль по использованию нейросетей для цифровизации бизнеса;
• для закрепления и расширения компетенций студент вправе выбрать дополнительный раздел, но уже за отдельную плату;
• выдается диплом российского и международного образцов;
• можно участвовать в очных встречах с экспертами и другими предпринимателями в крупных городах РФ;
• помощь с трудоустройством, включая возможности фриланса.

Недостатки:

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

Программа обучения:

• менеджмент в России и мире на современном этапе развития;
• операционная эффективность;
• управление кадровыми ресурсами бизнеса;
• финансы;
• командное управление, руководительский стиль;
• маркетинг: продвинутый уровень;
• основы современного предпринимательства.

Ознакомиться с полной программой >>>

4. Цифровая трансформация управления холдингом: системы, процессы и коммуникации | MBS

Мини-курс по цифровизации систем, коммуникаций и различных процессов современных предприятий. Уроки проводятся частично в классах и дистанционно по видеосвязи. В течение одного дня с 10:00 до 17:30 организованы занятия в аудитории. Далее около 10 академических часов — в онлайн-формате. Программа направлена на изучение теории и практики по цифровой трансформации именно холдинговых компаний.

• Стоимость: от 996 руб./мес. или 23 900 рублей
• Длительность: 1 день (18 часов)
• Формат обучения: дистанционный + очный
• Сертификат: двух образцов: Удостоверение о повышении квалификации и диплом института

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

Преимущества:

• прямой контакт с преподавателем курса во время занятий в аудитории;
• официальное подтверждение повышения квалификации;
• преподаватель — практикующий бизнес-тренер с профильным образованием;
• у наставника педагогический опыт около 10 лет, а в сфере бизнес-проектирования и цифровизации — более 20 лет;
• быстрый и круглосуточный ответ от технической поддержки (по номеру телефона или через мессенджер Telegram);
• оплачиваемый кофе-брейк во время очного занятия;
• MBS прошел государственное лицензирование в 2017 году;
• если не удалось приехать на офлайн-занятие в выбранную дату, его можно перенести на следующую по расписанию;
• много положительных отзывов о ведущем тренинга.

Недостатки:

• требуется посетить очный длительный урок в Москве — может не подойти тем студентам, которые живут не в столице.

Программа обучения:

• управление холдингом как единой IT-системой;
• контроль и мониторинг процессов бизнеса через технологии учета;
• цифровизация в управлении холдинговой компании;
• основы деловой психологии;
• управление проектами: теория и кейсы;
• функции и задачи менеджера холдинга;
• маркетинговые стратегии;
• контент-маркетинг и бренд-менеджмент.

Ознакомиться с полной программой >>>

5. Принципы управления изменениями в цифровой трансформации | MBA

Курс помогает понять, как максимально эффективно и быстро внедрить цифровые изменения в рутинные процессы любой компании, а также дает навыки в области управления, принятия решений и выстраивания стратегий. Все в аспекте цифровой трансформации, включая внедрение искусственного интеллекта. Программа длится двое суток по очной или заочной ставке (по выбору студента). Онлайн-вариант — это прохождение видео-лекций с небольшой обратной связью и тестами в конце.

• Стоимость: от 1 829 руб./мес. или 43 900 рублей
• Длительность: 2 дня
• Формат обучения: онлайн (видео-лекции) или офлайн (живые встречи по 7,5 часов в день)
• Сертификат: диплом от MBA или удостоверение о повышении квалификации

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

Преимущества:

• максимальный упор именно на практику и анализ реальных кейсов;
• предусмотрен диплом о повышении квалификации или сертификат Школы (зависит от имеющегося уровня образования);
• автор и педагог курса имеет 20 лет стажа в ИТ-сопровождении бизнеса;
• наставник — практикующий специалист в крупных компаниях, имеет преподавательский опыт;
• выгодные условия для юридических лиц и корпораций;
• после оплаты можно перенести дату на более позднюю, если не получается начать вовремя;
• служба поддержки на связи практически 24/7.

Недостатки:

• слишком короткая программа;
• не подходит для людей без опыта в управлении бизнесом.

Программа обучения:

• исторический аспект;
• влияние цифровой промышленной революции;
• анализ уровня цифровизации в компании;
• разработка технического задания по цифровой трансформации;
• расчет стоимости цифровизации;
• «дорожная» карта IT-трансформации;
• тестирование слушателей перед получением Удостоверения.

Ознакомиться с полной программой >>>

Еще 6 курсов по цифровой трансформации

Из всего разнообразия учебных планов по цифровизации предприятий мне было сложно ограничиться 5. Поэтому я собрала дополнительную подборку еще 6 курсов с положительными отзывами и насыщенной программой.

• Цифровая трансформация в бизнесе от МИПО — большая обучающая программа с выдачей диплома MBA (Мастер делового администрирования). Длится 9 месяцев, но пройти и сдать экстерном в два раза быстрее. Подходит топ-менеджерам, предпринимателям среднего и малого уровня, а также стартаперам и тем, кто только хочет создать свое дело. Обучение в режиме «онлайн» с вебинарами по видеосвязи, лекциями, упражнениями на основе реальных кейсов, тестами и проектами. Программа помогает повысить компетенции, получить повышение или новую должность.
• Руководитель цифровой трансформации от IAB — 318 часов теории и практики по управлению цифровизацией любой компании. Первое занятие является пробным, остальные по полной стоимости — 17 700 рублей. Благодаря лицензии IAB выдает дипломы государственного образца. Проходить уроки можно в любое удобное время, нет ограничений по длительности и расписания. Вести будут разные специалисты по продажам, эксперты в сфере ИТ-сопровождения, бизнесмены с педагогическим опытом, маркетологи и некоторые другие.
• Профессиональная переподготовка по программе «Цифровая трансформация» от Колледжа Цифровой Экономики и Технологии — этот дистанционный курс длительностью 3 месяца подходит для профессиональной переподготовки на базе Вуза или учреждения СПО по любой специальности. Имеются выгодные места для граждан РФ со льготами (ограничено по количеству и срокам подачи заявки). Уроки начинаются сразу после онлайн-оплаты на сайте. Не требуется ждать набора общей группы или следовать графику. Кураторы помогают на протяжении всего процесса — отвечают на вопросы, дают обратную связь по заданиям, оценивают итоговую работу. В конце по Почте России высылается физический вариант диплома.
• Цифровая трансформация. CDTO как руководитель нового типа от Специалист.ru — смешанное обучение (онлайн + офлайн). Всего 48 академических часов на уроки по программе. Пополам разделены на занятия в аудитории и записанные видео-лекции с дистанционной обратной связью. Возможен вариант полностью свободного обучения — все проводится в онлайн-формате без привязки к расписанию. Важно иметь предварительную подготовку по управлению бизнес-процессами, чтобы освоить программу курса. Один преподаватель для всех групп и форматов — Д.Ю. Динцис (ведущий педагог Специалист.ру, 38 лет педагогической практики, очень приятные отзывы).
• Руководитель цифровой трансформации от НБУ — более 300 часов практики и только нужная теория по цифровизации организаций. Попробовать вступительный урок можно бесплатно, познакомиться с наставником, подходом, понять, нужна ли именно эта программа. Включает в себя 18 частей: от международного предпринимательства до блокчейна. Выдается диплом российского образца с вкладышем международного стандарта. Сам университет работает еще с 2001 года, почти 25 лет.
• Цифровая трансформация для IT-руководителей от РАНХиГС — обучение в формате «выходного дня», то есть занятия по субботам и воскресеньям дважды в месяц. Обязательно иметь высшее или среднее профессиональное образование для прохождения курса (специализация не важна). Программа длится 314 часов. Общая стоимость — 196 тысяч рублей. Также в требованиях указывается опыт работы от двух лет, однако специализация не уточняется.

Soft Skills специалиста по цифровой трансформации бизнеса

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

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

Для развития hard skills (профессиональных навыков) лучше всего подходят специализированные курсы. Многие из них я описала в подборке выше. А вот развивать основные soft skills можно самостоятельно или по бесплатным урокам в сети Интернет. Однако имеются тренинги и учебные программы и для «мягких» навыков. Например, встречи с психологом-тренером по личностному росту, увеличения стрессоустойчивости или социализации. Они тоже помогут стать более востребованным и перспективным специалистом по цифровой трансформации. Дадут преимущество при отборе претендентов на работу. Поэтому развиваться желательно комплексно: и в профессиональном, и в личностном плане.

Сегодня диплом специалиста по цифровой трансформации «открывает» доступ к множеству вакансий на рынке труда в России и других странах. Полученные навыки помогают найти работу в маркетинге, аналитике и управлении. Вакансий конкретно по цифровой трансформации пока немного. Чаще работодатели ищут специалистов разных сфер с уже пройденными курсами цифровой трансформации и ИТ-сопровождению, например, бизнес-аналитиков, умеющих внедрять IT-технологии. Заработная плата подобных профессионалов начинается с 90 тысяч рублей по версии hh.ru.

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

Я изучила около 50 обучающих программ и отобрала 30 лучших курсов по автоматизации тестирования для этой статьи. В материале представлены топ-10 курсов, которые стоит рассмотреть в первую очередь, а также дополнительные варианты с акцентом на тестирование на Java и Python. Отдельно я собрала подборки бесплатных уроков и программ, которые помогут начать обучение самостоятельно.

Для некоторых курсов я даже нашла уникальные промокоды, которые позволят получить приятные скидки и бонусы при записи — отличная возможность сэкономить и начать обучение с дополнительными преимуществами!

ТОП-10 лучших курсов по автоматизации тестирования в 2026 году

1. Инженер по автоматизации тестирования от GeekBrains — комплексная программа с углубленным изучением Java, Python и JavaScript.
2. Инженер по автоматизации тестирования от Skillbox — практико-ориентированный курс с упором на Selenium и CI/CD.
3. Инженер по тестированию от Нетологии — расширенное обучение с модулями по нейросетям и современным фреймворкам.
4. Инженер по тестированию от Skypro — системная подготовка с созданием собственного фреймворка и дипломным проектом.
5. Ав­то­ма­ти­зи­ро­ван­ное тестирование на Python от Skillbox — обучение с акцентом на Python, Pytest и DevOps-практики.
6. Инженер по тестированию: от новичка до автоматизатора от «Яндекс Практикума» — поэтапное освоение от ручного тестирования до авто-тестов с реальными проектами.
7. Python QA Engineer от OTUS — интенсивный курс с PyTest, Selenium и упором на DevOps.
8. Автоматизатор тестирования на Java от «Яндекс Практикума» — обучение Java с нуля и построение CI/CD пайплайнов.
9. Инженер по автоматизированному тестированию на JavaScript от «Хекслета» — практика с Playwright, Jest и проектами на GitHub.
10. Автоматизатор тестирования на Python от «Яндекс Практикума» — обучение на Python с упором на pytest, Selenium и Docker.

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

Онлайн-курсы по автоматизации тестирования

1. Инженер по автоматизации тестирования | GeekBrains

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

Программа охватывает три популярных языка программирования — Java, Python и JavaScript. Студенты осваивают современные инструменты и практики: Selenium WebDriver, JUnit, Chrome DevTools, Postman, GitLab, Grafana, SQL и Jira. Вы также научитесь созданию автотестов для веб- и мобильных приложений, работе с API и внедрению непрерывной интеграции.

Обучение ведут практикующие эксперты из Ozon, СКБ «Контур» и других крупных компаний. Курс сочетает теоретические видеоуроки с практикой на реальных проектах, что позволяет студентам формировать портфолио уже во время обучения.

• Стоимость: от 3 358 руб. в месяц при рассрочке
• Длительность: 110 часов теории и 400 часов практики
• Формат обучения: видеоуроки, вебинары, практические задания, проекты, консультации кураторов и проверка домашних заданий
• Сертификат: официальный диплом с лицензией

Кому подойдет: начинающим QA-инженерам, тестировщикам с опытом ручного тестирования, разработчикам, которые хотят освоить автоматизацию.

Преимущества

• совместная программа GeekBrains и Skillbox;
• обучение с лицензией государственного образца;
• углубленное изучение Java, Python и JavaScript;
• работа с современными инструментами для тестирования;
• большой объем практики на реальных кейсах;
• персональная обратная связь от экспертов;
• возможность собрать портфолио во время обучения;
• поддержка HR-специалистов для выхода на рынок труда;
• гибкий график и доступ к материалам в любое время;
• рассрочка без переплат и налоговый вычет.

Недостатки

• высокая нагрузка по практическим заданиям;
• продолжительный срок обучения.

Программа обучения:

• Изучение одного из языков программирования Java/JavaScript/Python
• Создание первых автотестов с использованием Selenium
• Продвинутое автоматизированное тестирование
• Работа с SQL для тестирования баз данных
• Использование Jira для постановки задач и баг-репортов
• Работа с API и Postman
• Настройка CI/CD процессов
• Метрики тестирования и их применение
• Создание UI-тестов
• Итоговые проекты и защита портфолио

Ознакомиться с полной программой >>>

2. Инженер по автоматизации тестирования | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 60%

Получить скидку >>>

Студенты осваивают один из трех языков программирования — Java, Python или JavaScript, знакомятся с современными инструментами, такими как Selenium WebDriver, JUnit, Git и CI/CD, и уже с первых модулей применяют знания на практике, создавая проекты для портфолио.

Обучение ведут практикующие эксперты из крупных компаний, а доступ к видеолекциям остается бессрочным, что позволяет повторять материал и углублять знания. Курс сочетает теорию с практическими заданиями, включает работу с API и SQL, а также предоставляет поддержку в подготовке к трудоустройству, помогая студентам уверенно стартовать в профессии инженера по автоматизации тестирования.

• Стоимость: от 5 382 руб. в месяц при рассрочке
• Длительность: 9 месяцев
• Формат обучения: видеолекции, практические задания, проекты, вебинары, кураторская поддержка и доступ к мобильной версии платформы
• Сертификат: официальный документ с лицензией

Кому подойдет: junior-тестировщикам, студентам курса «Инженер по тестированию» для продолжения обучения, специалистам, которые хотят перейти от ручных проверок к автоматизации.

Преимущества

• обучение с лицензией государственного образца;
• освоение Java, Python и JavaScript;
• практика с первого модуля;
• работа с Selenium IDE и WebDriver;
• изучение CI/CD и GitLab;
• доступ к видеоурокам навсегда;
• мобильная версия платформы;
• помощь кураторов и экспертов;
• дополнительные модули по SQL и API;
• участие в двух финальных проектах;
• возможность пополнить портфолио практическими кейсами;
• обучение с опытными спикерами из OZON и СКБ «Контур»;
• налоговый вычет до 13% от стоимости курса.

Недостатки

• курс рассчитан только на специалистов с базовыми знаниями ручного тестирования;
• ограничение по языкам программирования (только Java, Python, JavaScript);
• трудоустройство не гарантировано, есть лишь канал с вакансиями.

Программа обучения

• Изучение одного из языков программирования Java/JavaScript/Python
• Первые автотесты во фреймворке Selenium
• Продвинутое автоматизированное тестирование
• Настройка CI/CD и параллельных запусков тестов
• Работа с SQL и тестирование баз данных
• Создание UI-тестов и их интеграция в процесс разработки
• Работа с Git и управление версиями кода
• Тестирование API и практические задачи с Postman
• Итоговые проекты и защита работ

Ознакомиться с полной программой >>>

3. Инженер по тестированию | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Получить скидку >>>

Программа построена поэтапно: сначала студенты изучают ручное тестирование веб- и мобильных приложений, затем переходят к автоматизированным сценариям на Python или Java, а в расширенном блоке осваивают JavaScript и популярные фреймворки — Cypress, Playwright и Puppeteer. Курс также включает модули по SQL, тестированию API, нагрузочному тестированию сервисов, анализу сетевого трафика и базовым практикам безопасности с использованием OWASP ZAP и Burp Suite.

Дополнительно студенты знакомятся с Docker, Git, Postman и JMeter, учатся планировать автоматизацию и анализировать результаты тестов. Четыре блока посвящены применению нейросетей для генерации кода автотестов, оптимизации рутинных задач и подготовки документации. В течение курса выполняется более 20 практических проектов, включая групповые задания на основе кейсов от компаний Dragons, OneTwoTrip, QIWI и «Глобус ИТ».

• Стоимость: от 3 816 руб. в месяц при рассрочке
• Длительность: 14 месяцев (408 часов практики)
• Формат обучения: вебинары, видеолекции, тренажеры для работы с кодом, домашние задания, проекты, командные кейсы, практические вебинары и поддержка экспертов в чате
• Сертификат: диплом о профессиональной переподготовке установленного образца

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

Преимущества

• обновленная программа 2026 года с модулями по нейросетям;пошаговое погружение от ручного тестирования до автоматизации;
• 20 крупных проектов для портфолио;
• командная практика по реальным кейсам от партнеров;
• изучение Python, Java и JavaScript на выбор;
• освоение популярных фреймворков для автоматизации;
• практика работы с SQL и тестированием API;
• модули по нагрузочному и функциональному тестированию;
• основы тестирования безопасности и анализа уязвимостей;
• знакомство с Docker и CI/CD;
• поддержка экспертов из VK, Т-Банка, QIWI и других компаний;
• доступ к мобильному приложению для обучения;
• помощь в трудоустройстве и сопровождение после выпуска.

Недостатки

• курс рассчитан на системное освоение, быстрых результатов не будет.

Программа обучения

• Ручное тестирование веб-приложений
• Git и система контроля версий
• Python для тестировщиков или Java для тестировщиков
• Автоматизированное тестирование на Python или Java
• JavaScript и фреймворки для автоматизации
• Тестирование API и интеграция в CI
• Нагрузочное тестирование сервисов
• Тестирование мобильных приложений
• Основы тестирования безопасности
• Работа с Docker и CI/CD
• Дополнительные модули по нейросетям для тестировщиков
• Итоговые проекты и дипломная работа

Ознакомиться с полной программой >>>

4. Инженер по тестированию | Skypro

Используйте промокод Kursfinder, чтобы получить скидку 10%

Получить скидку >>>

Программа построена так, чтобы студенты постепенно осваивали как ручное, так и автоматизированное тестирование. Сначала слушатели изучают работу с баг-репортами, тест-кейсами и системами управления тестами, затем переходят к освоению баг-трекинговых сервисов, методик тест-дизайна, регрессионного и дымового тестирования. Используются Chrome DevTools, Postman, SoapUI, SQL и JMeter для анализа работы веб-платформ, API и баз данных.

Дальше курс погружает студентов в автоматизацию на Python и Java, работу с Pytest, библиотекой requests и формирование отчетности в Allure. Студенты создают UI-тесты с помощью Selenium, изучают CI/CD и практикуются с Docker для автоматизации запуска тестов. В рамках обучения разрабатывается собственный тестовый фреймворк, а завершающим этапом становится дипломный проект. Программа насыщена практическими заданиями — около 70% материалов основаны на реальных кейсах работодателей и фриланс-платформ, что позволяет выпускникам сформировать полноценное портфолио к концу курса.

• Стоимость: от 5 972 руб. в месяц при рассрочке
• Длительность: 12 месяцев
• Формат обучения: онлайн-занятия, видеолекции, практические задания, работа с наставниками, тренажеры, проекты и дипломная работа
• Сертификат: диплом о профессиональной переподготовке

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

Преимущества

• системная программа с базовыми и продвинутыми блоками;
• 70% практики на реальных задачах;
• изучение баг-трекинговых систем и TMS;
• работа с Chrome DevTools и кросс-браузерным тестированием;
• освоение Postman и SoapUI;
• практика с SQL и нагрузочным тестированием в JMeter;
• автоматизация тестов на Python и Java;
• знакомство с Pytest и библиотекой requests;
• отчетность и визуализация через Allure;
• практика с Selenium WebDriver;
• освоение принципов CI/CD и Docker;
• создание собственного фреймворка для автотестов;
• карьерные консультации и помощь в трудоустройстве.

Недостатки

• длительный срок обучения (1 год);
• упор на Python и Java, другие языки не рассматриваются.

Программа обучения

• Основы функционального тестирования
• Работа с баг-репортами и баг-трекинговыми системами
• Тест-кейсы и системы управления тестами
• Уровни тестирования и тест-дизайн
• Smoke- и регрессионное тестирование
• Тестирование документации и метрики
• Тестирование веб-приложений и работа с HTML/CSS
• Chrome DevTools и кросс-браузерное тестирование
• Git и основы CI/CD
• Тестирование API с Postman и SoapUI
• Нагрузочное тестирование с JMeter
• Основы SQL и работа с базами данных
• Автоматизация тестирования на Python или Java
• Pytest, requests и Allure для отчетности
• UI-тесты и Selenium WebDriver
• Docker и настройка CI/CD процессов
• Дипломный проект и защита портфолио

Ознакомиться с полной программой >>>

5. Ав­то­ма­ти­зи­ро­ван­ное тестирование на Python | Skillbox

Используйте промокод kursfinder, чтобы получить скидку 50%

Получить скидку >>>

На занятиях студенты осваивают написание чистого кода на Python, применяют принципы объектно-ориентированного и функционального программирования, разрабатывают архитектуру тестов и объединяют их в тестсьюты. Особое внимание в программе уделяется работе с DevTools и PyCharm, использованию Pytest и Selenium для построения автотестов, а также созданию сценариев на основе паттернов тестирования.

Отдельные блоки посвящены DevOps-инструментам: студенты интегрируют тесты в Jenkins, настраивают параллельные и последовательные проверки и внедряют их в CI/CD-процессы. Курс также охватывает работу с Git, решение конфликтов версий и ведение командных проектов. Теория сразу закрепляется практикой, а итогом становится полноценное портфолио готовых кейсов. Программу ведут эксперты: Дарья Манухина, специалист с опытом работы в МТС и Skyeng, и Павел Громов, backend-разработчик с практикой преподавания и участия в конференциях по тестированию.

• Стоимость: от 5 028 руб. в месяц при рассрочке
• Длительность: 9 месяцев
• Формат обучения: онлайн-лекции, практические задания, вебинары, индивидуальная проверка домашних работ кураторами, обратная связь и доступ к материалам без ограничения по времени
• Сертификат: диплом о профессиональной переподготовке

Кому подойдет: начинающим тестировщикам, которые хотят с нуля освоить Python и автоматизацию; junior-специалистам для повышения уровня знаний; middle-инженерам по тестированию, желающим закрепить практику и выйти на новый уровень.

Преимущества

• обучение с упором на Python;
• освоение Pytest и Selenium;
• практика с DevTools и PyCharm;
• изучение принципов тест-дизайна;
• написание автотестов для реальных кейсов;
• построение архитектуры тестов и паттернов;
• работа с Jenkins и CI/CD;
• интеграция тестов с Git;
• коммит, merge и разрешение конфликтов версий;
• практика на примере веб- и API-проектов;
• участие экспертов-практиков;
• доступ к курсу навсегда;
• бесплатный бонус — год английского языка.

Недостатки

• упор на один язык программирования;
• значительный объем теории, требующий регулярной практики;
• курс рассчитан на 9 месяцев, быстрых результатов не будет;ограничение по выбору инструментов вне экосистемы Python.

Программа обучения

• Python Basic
• Python Advanced
• Введение в автоматизацию тестирования API
• Автотесты на Python. Базовая часть
• Автотесты на Python. Продвинутая часть
• DevOps для тестировщиков
• Итоговые проекты и дипломная работа

Ознакомиться с полной программой >>>

6. Инженер по тестированию: от новичка до автоматизатора | Яндекс Практикум

Купите любой курс с выгодой до 20% при оплате сразу или получите скидку 7% за прохождение бесплатной части курса за неделю

Получить скидку >>>

Обучение начинается с освоения принципов тестирования приложений и работы с тестовой документацией, после чего студенты переходят к созданию автотестов на Java или Python. В программе используются инструменты Charles, Postman, Swagger, DevTools, Selenium WebDriver, Pytest, Allure и Jenkins, а также SQL для работы с базами данных. Знания сразу закрепляются практикой: за время курса слушатели выполняют 10 реальных проектов, формируя портфолио для будущего трудоустройства.

Вы научитесь также тестированию веб- и мобильных приложений, API и работе с инфраструктурой, что позволяет применять навыки в различных сферах — от банковских сервисов до игровых компаний. Обучение проводят эксперты из Яндекса и крупных IT-компаний, включая Константина Булатова, Кристину Тимошенко и Романа Орлова. Дополнительно студенты изучают применение нейросетей в тестировании и получают навыки подготовки резюме для привлечения работодателей.

• Стоимость: от 3 225 руб./мес или 79 000 руб. единым платежом
• Длительность: 9 месяцев
• Формат обучения: вебинары с практикующими тестировщиками, видеолекции, интерактивный учебник, командные проекты, поддержка наставников и ревьюеров, доступ к материалам навсегда
• Сертификат: диплом о профессиональной переподготовке от АНО ДПО «Образовательные технологии Яндекса»

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

Преимущества

• освоение ручного и автоматизированного тестирования;
• выбор языка для автотестов (Java или Python);
• практика на 10 реальных проектах;
• инструменты Charles, Postman, Swagger, SQL, Selenium, Jenkins;
• работа с мобильными приложениями и API;
• модуль по применению нейросетей;
• обучение у специалистов Яндекса и EPAM;
• поддержка наставников и ревьюеров;
• доступ к материалам курса без ограничений;
• помощь в трудоустройстве через карьерный центр;
• возможность совмещать учебу с работой;
• налоговый вычет до 19 500 руб.;
• гарантия возврата средств при отказе от курса.

Недостатки

• высокая учебная нагрузка (от 15 часов в неделю);
• основной упор на начинающих.

Программа обучения

• Бесплатный вводный модуль
• Основы тестирования
• Регрессионное тестирование и ретест багов
• Тестирование фичи от анализа до баг-репорта
• Расширенное тестирование веб-приложений
• Тестирование мобильных приложений
• Тестирование API
• Основы баз данных
• Автоматизированное тестирование на Java
• Автоматизированное тестирование на Python
• Итоговый проект
• Нейросети для тестировщиков
• Карьерный трек

Ознакомиться с полной программой >>>

7. Python QA Engineer | OTUS

Программа построена так, чтобы студенты научились работать с фреймворком PyTest, автоматизировать UI- и API-тесты, использовать Selenium 4 и Appium, проводить тестирование REST API и настраивать процессы в системах непрерывной интеграции. Выпускники осваивают запуск автотестов в CI/CD, анализ результатов и работу с инфраструктурой.

Преподаватели-практики объясняют материал на реальных кейсах и проводят вебинары с возможностью задавать вопросы и получать подробную обратную связь. Учебный процесс включает не только теорию, но и регулярные практические задания, работу с инструментами диагностики в Linux, а также итоговый проект, в рамках которого студенты создают собственный тестовый фреймворк, пишут UI- и API-тесты и защищают проект перед экспертами.

• Стоимость: 121 000 руб. (есть рассрочка и налоговый вычет до 13%)
• Длительность: 6 месяцев
• Формат обучения: вебинары дважды в неделю, доступ к записям и материалам, практические задания, выпускной проект, поддержка в закрытом чате
• Сертификат: официальный сертификат OTUS о прохождении курса

Кому подойдет: ручным тестировщикам, желающим освоить автоматизацию; специалистам, работающим с другими языками, и планирующим перейти на Python; QA-инженерам, которые хотят углубить знания и систематизировать навыки.

Преимущества

• упор на практику с реальными кейсами;
• изучение PyTest как основного фреймворка;
• работа с Selenium 4 и Appium;
• тестирование REST API;
• освоение DevOps-практик;
• использование Linux для диагностики;
• обучение у экспертов-практиков;
• участие в живых вебинарах;
• обратная связь по домашним заданиям;
• доступ к закрытому сообществу;
• выпускной проект для портфолио;
• доступ к репозиторию с примерами тестов;
• возможность оплаты курса работодателем.

Недостатки

• обязательное вступительное тестирование перед началом;
• курс рассчитан на студентов с базовыми знаниями Python;
• высокая учебная нагрузка (две вечерние сессии в неделю).

Программа обучения

• Введение в автоматизацию тестирования
• Тестирование API
• Тестирование UI
• DevOps
• Мобильное тестирование
• Работа с бэкендом
• Другие виды тестирования
• Подготовка к поиску работы
• Проектный модуль и защита выпускного проекта

Ознакомиться с полной программой >>>

8. Автоматизатор тестирования на Java | Яндекс Практикум

Купите любой курс с выгодой до 20% при оплате сразу или получите скидку 7% за прохождение бесплатной части курса за неделю

Получить скидку >>>

В рамках курса студенты осваивают основы языка Java, учатся писать код и применять его для создания автотестов для веб-приложений и API. Программа включает популярные инструменты тестировщика: IntelliJ IDEA, Maven, Git, Selenium WebDriver, Selenide, JUnit, Postman, REST Assured, Allure и Jenkins. Шаг за шагом слушатели погружаются в процесс автоматизации — от базовых конструкций и написания юнит-тестов до разработки архитектуры тестирования и построения полноценного пайплайна CI/CD.

Отдельные блоки посвящены тестированию интерфейсов, API и баз данных, а также внедрению подхода Behavior-Driven Development с использованием Cucumber и Gherkin. На занятиях студенты выполняют проекты, максимально приближенные к реальным задачам индустрии, и получают обратную связь от опытных специалистов. Завершающим этапом курса становится итоговая работа, где необходимо покрыть автотестами веб-приложение, API и написать юнит-тесты, объединяя все полученные навыки.

• Стоимость: от 4 204 руб. в месяц (есть рассрочка и налоговый вычет)
• Длительность: 5–6 месяцев (в зависимости от тарифа)
• Формат обучения: онлайн-лекции, интерактивные задания в тренажере, вебинары каждые 2 недели, проекты для портфолио, индивидуальные встречи с наставником, обратная связь от экспертов
• Сертификат: диплом о профессиональной переподготовке

Кому подойдет: ручным тестировщикам, которые хотят перейти в автоматизацию; junior-специалистам, готовым укрепить навыки и освоить Java; действующим QA-инженерам, планирующим карьерный рост.

Преимущества

• освоение Java с нуля;
• обучение работе с IntelliJ IDEA и Maven;
• практика с Git и GitHub;
• изучение юнит-тестирования на JUnit 5;
• знакомство с Mockito и DI;
• написание автотестов с Selenium и Selenide;
• тестирование интерфейсов через DevTools;
• автоматизация API с использованием Postman и REST Assured;
• отчетность в Allure;
• построение пайплайнов CI/CD в Jenkins;
• работа с Docker и Kubernetes;
• освоение BDD и Cucumber;
• проектная работа для портфолио.

Недостатки

• требуется регулярное выделение времени (не менее 15 часов в неделю);
• часть материалов доступна только в расширенной версии.

Программа обучения

• Введение в профессию и основы Git
• Изучение Java: базовый и продвинутый уровни
• Объектно-ориентированное программирование и базовые конструкции
• Юнит-тестирование и работа с JUnit, Mockito
• UI-тестирование на Selenium и Page Object Model
• Тестирование API с Postman, Swagger, REST Assured
• Работа с базами данных и SQLCI/CD, Docker, Kubernetes, Jenkins
• Behavior-Driven Development с Cucumber и Gherkin
• Работа с асинхронными сервисами и Kafka
• Итоговый проект и защита работы

Ознакомиться с полной программой >>>

9. Инженер по автоматизированному тестированию на JavaScript | Хекслет

С первых занятий студенты начинают программировать на JavaScript, осваивают построение автотестов и их применение к реальным веб-приложениям. Вы научитесь работе с Playwright и Jest, а также интеграционному, модульному и e2e-тестированию. Обучение построено на практических заданиях и проектах: студенты пишут автотесты для учебных сервисов, работают с Git, осваивают CI/CD и Docker, создавая полноценные проекты для портфолио.

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

• Стоимость: от 85 000 руб. (есть рассрочка и акции)
• Длительность: 8 месяцев
• Формат обучения: теория в текстовом и видеоформате, практические задания, проекты на GitHub, домашние упражнения, вебинары, код-ревью и наставничество
• Сертификат: официальный документ Хекслета, ценимый работодателями

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

Преимущества

• упор на практику с первых занятий;
• изучение JavaScript в контексте тестирования;
• освоение Playwright для UI-тестов;
• работа с Jest и Vitest для модульного тестирования;
• интеграция Git и командной строки в учебный процесс;
• проекты с реальными бизнес-задачами;
• портфолио на GitHub с завершенными проектами;
• коммерческие задачи от партнеров;
• наставничество от опытных инженеров;
• карьерное сопровождение через Хекслет.Карьеру;
• подготовка резюме и собеседований;
• поддержка при трудоустройстве;
• возможность академического отпуска при необходимости.

Недостатки

• интенсивный формат может быть сложен для новичков;
• часть проектов предполагает самостоятельное погружение без пошаговых инструкций.

Программа обучения

• Основы JavaScript и настройка окружения
• Работа с Git и командной строкой
• Юнит- и интеграционное тестирование на Jest
• Асинхронное программирование и тестирование API
• E2E-тестирование с Playwright
• Работа с HTML, CSS и DOM API
• Тестирование бэкенда и взаимодействие с базами данных
• CI/CD и основы Docker
• Учебные и коммерческие проекты для портфолио
• Итоговый проект с полной автоматизацией веб-приложения

Ознакомиться с полной программой >>>

10. Автоматизатор тестирования на Python | Яндекс Практикум

Купите любой курс с выгодой до 20% при оплате сразу или получите скидку 7% за прохождение бесплатной части курса за неделю

Получить скидку >>>

Студенты осваивают базовый синтаксис Python и сразу начинают применять его для написания автотестов. Программа включает работу с pytest, Selenium WebDriver, Allure, Git, DevTools, а также использование XPath и CSS-локаторов. Вас научат архитектуре приложений, методам тестирования API и организации тестовых сценариев. Обучение строится на практике: студенты создают проекты для портфолио, покрывают тестами веб-приложения, API и пишут юнит-тесты с использованием моков, стабов и Spy. Курс разработан опытными инженерами по тестированию из Яндекса и других крупных IT-компаний, что гарантирует актуальность материалов и их связь с реальной индустрией.

Теоретический материал подается в удобной форме и закрепляется интерактивными заданиями в тренажере, а регулярные вебинары позволяют разбирать сложные кейсы вместе с экспертами. В результате выпускники получают навыки построения процессов автоматизации, работы с CI/CD и Docker, а также опыт создания комплексных отчетов о тестировании. Дополнительно студенты формируют портфолио с реальными проектами, которое подтверждает их компетенции перед работодателями.

• Стоимость: от 4 204 руб. в месяц (есть рассрочка и налоговый вычет)
• Длительность: 5–6 месяцев (в зависимости от тарифа)
• Формат обучения: видеолекции и текстовые материалы, тренажер для практики, домашние задания, вебинары каждые 2 недели, проекты для портфолио, обратная связь от наставников
• Сертификат: диплом о профессиональной переподготовке или справка об обучении

Кому подойдет: ручным тестировщикам, стремящимся перейти в автоматизацию; инженерам QA, которые хотят повысить квалификацию; айти-специалистам, решившим освоить новое направление.

Преимущества

• обучение на Python с нуля;
• освоение pytest для юнит-тестов;
• практика с Selenium WebDriver;
• работа с DevTools и XPath;
• создание отчетов в Allure;
• тестирование API с Postman и Swagger;
• изучение принципов архитектуры приложений;
• работа с базами данных и SQL;
• освоение CI/CD и Docker;
• практика в реальных проектах;
• 7–10 проектов для портфолио;
• доступ к вебинарам и Q&A-сессиям;
• поддержка наставников и экспертов Яндекса.

Недостатки

• высокая нагрузка (нужно минимум 15 часов в неделю);
• часть тем и проектов доступна только в расширенной версии;
• полностью онлайн-формат без живых встреч;
• для новичков могут быть сложны темы ООП и CI/CD.

Программа обучения

• Введение и знакомство с Git
• Основы Python и базовые конструкции
• Объектно-ориентированное программирование
• Инкапсуляция и обработка исключений
• Юнит-тестирование с использованием pytest
• UI-тестирование на Selenium и DevTools
• Применение Page Object Model и Allure
• Тестирование API и работа с Postman, Swagger
• Основы архитектуры и организация процессов тестирования
• Итоговый проект с полной автоматизацией веб-приложения
• Дополнительный модуль по SQL и тестированию баз данных
• CI/CD и работа с Docker (в расширенной версии)

Ознакомиться с полной программой >>>

Еще 4 курса по автоматизации тестирования

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

• QA-инженер по тестированию: с нуля до автоматизатора от «Хекслета». Курс построен так, чтобы с нуля подготовить специалиста к профессии QA-инженера и постепенно довести его до уровня автоматизатора на JavaScript. В программе много практики: студенты тестируют реальные веб- и мобильные приложения, пишут баг-репорты, создают автотесты с использованием Vitest и Playwright, осваивают работу с API и SQL. Обучение сопровождается проектами для портфолио и консультациями наставников, а завершение курса подтверждается сертификатами по двум профессиям.
• Тестировщик в IT от Yagla. Курс рассчитан на тех, кто хочет быстро войти в IT и освоить профессию тестировщика с нуля. Программа охватывает ручное и автоматизированное тестирование, работу с базами данных, инструментами Git, SQL, Selenium, Postman и другими технологиями. Обучение построено на практике и реальных кейсах, к окончанию курса формируется портфолио и выдается сертификат, подтверждающий квалификацию.
• Тестирование с Pytest от «Хекслета». Курс обучает работе с Pytest и современными техниками автоматизированного тестирования на Python. Студенты осваивают модульные тесты, фикстуры, подход TDD, а также продвинутые инструменты вроде моков, стабов и манкипатчинга. Занятия построены на практике с использованием виртуальной среды и автоматической проверкой решений, что позволяет сразу закреплять полученные знания.
• Инженер по тестированию от Skillbox. Программа готовит специалистов по ручному и автоматизированному тестированию с упором на современные ИИ-инструменты. В процессе обучения студенты осваивают Java, Python или JavaScript для написания автотестов, учатся работать с Postman, Selenium, SQL, Git и Unity, а также тестируют реальные проекты от компаний-партнеров. В курс добавлены блоки по тестированию мобильных приложений и игр, что расширяет возможности трудоустройства и формирует сильное портфолио.

Еще 2 курса по автоматизации тестирования на Java

Если вы хотите углубить знания в автоматизации тестирования на Java, эти два курса станут отличным выбором. Они помогут закрепить навыки создания автотестов, работы с современными инструментами и подготовят к реальным задачам в IT-индустрии.

• Автоматизация тестирования ПО (Java). Basic от Level Up. Курс знакомит с основами автоматизации тестирования на Java и учит применять популярные инструменты вроде Selenium, Selenide, Cucumber, JUnit и RestAssured. Обучение построено на сочетании теории и практики, предполагает работу с CI/CD и Jenkins, а также формирование базовых навыков написания автотестов. По окончании программы студенты получают представление о роли инженера по автоматизации и приобретают навыки, достаточные для работы на позиции junior.
• Автоматизированное тестирование ПО на Java от Университета «Иннополис». Программа знакомит с автоматизацией тестирования на Java и учит работать с ключевыми инструментами — Selenium, Selenide, RestAssured, Docker и CI/CD. Студенты осваивают написание автотестов для UI и API, работу с базами данных и основы BDD. Обучение построено на практических заданиях и завершается дипломом о профессиональной переподготовке, что позволяет претендовать на позиции AQA-инженера.

Еще 4 курса по автоматизации тестирования на Python

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

• Автоматизация тестирования на Python от «Контур.Школы». Программа обучает автоматизации тестирования на Python и помогает создавать автотесты для API, мобильных и веб-приложений. В процессе занятий студенты осваивают PyTest, Selenium, а также принципы Page Object Model. Курс сочетает теорию с практическими задачами и завершается итоговым тестом, после которого выдается официальный документ о повышении квалификации.
• Тестировщик на Python от SkillFactory. Программа обучает ручному и автоматизированному тестированию, в том числе работа с Python, PyTest, Selenium, SQL и REST API. В процессе обучения студенты выполняют проекты от реальных компаний, составляют баг-репорты и тест-кейсы, проходят практику на коммерческих сервисах. По окончании выдается диплом о профессиональной переподготовке или сертификат, что позволяет претендовать на позиции тестировщика и QA-инженера.
• Автоматизированное тестирование на Python от EasyUM. Курс помогает освоить автоматизацию тестирования на Python с нуля и шаг за шагом перейти к созданию автотестов для веб-приложений и API. В программе есть работа с PyTest, Selenium, Docker и Jenkins, а также основы DevOps. Обучение построено на практике, есть реальные задания и проекты для портфолио, а по завершении выдается сертификат и проводится подготовка к трудоустройству.
• Автоматизированное тестирование на Python от Teachmeskills. Курс учит создавать автотесты на Python с использованием Selenium, PyTest, Docker и Jenkins. В процессе обучения студенты осваивают тестирование API и веб-приложений, а также работу с базами данных и Linux. Программа построена на практике, предполагает также разработку реального проекта для портфолио и завершается защитой диплома с поддержкой в трудоустройстве.

Бесплатные курсы по автоматизации тестирования

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

1. Легкий старт в профессию тестировщика — Skillbox

Этот интенсив подойдет новичкам, которые хотят попробовать себя в тестировании и понять, насколько им близка эта профессия. За несколько дней слушатели познакомятся с базовыми принципами ручного и автоматизированного тестирования, узнают о юзабилити и стандартах работы в IT-компаниях. Участники получат практику в поиске ошибок, составлении баг-репортов и запуске первых автотестов с помощью Selenium IDE. Такой формат обучения позволяет быстро погрузиться в профессию и сформировать первые навыки.

Главное о курсе:

• знакомство с процессами тестирования и профессией QA;проведение первых автотестов с использованием Selenium IDE;
• освоение правил юзабилити и нефункционального тестирования;
• практика в составлении баг-репортов и работе с ошибками;
• выполнение интерактивных заданий на реальных примерах.

2. Основы Java для автоматизации тестирования — Stepik

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

Главное о курсе:

• базовые знания языка Java и основы ООП;
• создание первых программ и работа с массивами, строками и классами;
• использование принципов инкапсуляции, наследования и полиморфизма;
• практика обработки исключений и документирования кода;
• более 70 часов обучения с тестами и интерактивными заданиями.

3. Тестировщик программного обеспечения: с нуля до первых проектов — «Содействие занятости»

Курс предназначен для тех, кто хочет освоить профессию тестировщика с нуля и получить востребованные навыки работы с современными инструментами. Он подойдет людям, ищущим работу, желающим сменить профессию или повысить квалификацию. Программа дает понимание основ тестирования, практику работы с SQL и Postman, а также опыт оформления баг-репортов. Обучение бесплатное, проводится онлайн и завершается выдачей документа установленного образца.

Главное о курсе:

• знакомство с базовыми принципами тестирования ПО;
• работа с тестовой документацией и баг-репортами;
• практика в SQL и тестировании API через Postman;
• использование инструментов Jira, Яндекс Трекера, TestRail и DevTools;
• выполнение итогового проекта и получение удостоверения о квалификации.

4. Автоматизация тестирования с помощью Selenium и Python — Stepik

Курс рассчитан на начинающих специалистов в тестировании, которые хотят перейти к автоматизации и освоить работу с Python и Selenium. Он подойдет тем, кто уже знаком с базовой терминологией QA и хочет научиться писать автотесты для веб-интерфейсов. Программа помогает освоить популярные фреймворки, применить хорошие практики проектирования тестов и получить навыки, востребованные на рынке. Обучение бесплатное и завершается сертификатом.

Главное о курсе:

• написание автотестов на Python с использованием Selenium;
• работа с веб-элементами и построение стабильных тестов;
• применение pytest и других фреймворков для автоматизации;
• использование паттерна PageObject для удобной поддержки сценариев;
• практика работы с git и Github.

5. Тесты и тренажеры для тестировщиков — LearnQA

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

Главное о курсе:

• тесты по Git, SQL, Java, Bash и базовым знаниям IT;
• тренажеры с эмуляцией рабочих ситуаций и поиском багов;
• подготовка к собеседованиям через практические задания;
• возможность закрепить знания и проверить себя в удобном формате.

Видеоуроки по автоматизации тестирования

Я предлагаю не игнорировать, а просмотреть и видеоуроки по автоматизации тестирования, чтобы еще глубже понять тему. Это дает возможность наглядно увидеть процесс работы и повторить действия за преподавателем. Видео поможет закрепить теорию и быстрее перейти к практике.

1. Введение в автоматизацию для QA — Simple Automation. Плейлист подойдет тем, кто хочет разобраться в автоматизации тестирования с нуля и получить базовые навыки работы с основными инструментами. Видеоуроки построены последовательно — от теории и языка Java до работы с Git, Maven, JUnit, REST Assured и Selenium WebDriver. Такой формат помогает шаг за шагом освоить практику и закрепить знания через наглядные примеры.
2. Автоматизация тестирования с Pytest и Python — SolveMe. Плейлист подойдет тем, кто хочет научиться работать с Pytest и применять Python для автоматизации тестирования на практике. В уроках разбираются базовые приемы написания автотестов, работа с фикстурами, декораторами и генерацией отчетов. Отдельные видео посвящены использованию Pydantic, SQLAlchemy и Docker, что позволяет получить более глубокое понимание современного тестирования.
3. Автоматизация тестирования java + selenium webdriver — Алексей Маршал. Плейлист поможет тем, кто хочет освоить автоматизацию тестирования на Java с использованием Selenium WebDriver. В видеоуроках объясняются основы работы с DOM, локаторами, XPath и CSS-селекторами, а также показано, как взаимодействовать с элементами интерфейса. Отдельное внимание уделяется ожиданиям, работе с модальными окнами, вкладками браузера и построению фреймворка на основе PageObject.
4. Автоматизация на пальцах — Стас Пешкур. Плейлист создан для тех, кто хочет разобраться в автоматизации тестирования на практике и понять ее основы простым языком. В видео разбираются ключевые инструменты и подходы, работа с API-тестами, использование Rest Assured, Cucumber, Selenide и Page Object. Также показаны примеры настройки Maven, Jenkins и Gitlab CI/CD, создания отчетов в Allure и отладки кода на реальных задачах.
5. QA с нуля — Александр Хвастович. Этот плейлист подойдет тем, кто только начинает путь в тестировании и хочет понять основы профессии с нуля. В видеоуроках разбираются ключевые темы — от базовых принципов QA и методологий разработки до тестовой документации, работы с Jira, Git и SQL. Формат построен так, чтобы постепенно вести новичка от теории к первым практическим навыкам и подготовке к старту карьеры в IT.

Часто задаваемые вопросы (FAQ)

Курсы по автоматизации тестирования на Python стабильно занимают верхние позиции в рейтингах IT-обучения. Это объясняется сочетанием доступности языка, высокой востребованности специалистов и тем, что такие программы рассчитаны даже на новичков без опыта. Мы собрали ответы на самые популярные вопросы, которые помогают понять, чего ожидать от обучения и как строится процесс подготовки.

Почему именно курсы по автоматизации тестирования на Python пользуются наибольшим спросом среди новичков в IT?

Python отличается простым синтаксисом и богатым набором инструментов для тестирования. В курсах Skillbox и Яндекс Практикума студенты начинают с основ языка и сразу переходят к работе с Pytest и Selenium, что позволяет быстро освоить профессию и собрать портфолио.

За какой срок реально перейти от нуля до трудоустройства в профессии тестировщика-автоматизатора на Python?

Срок зависит от программы: от 5–6 месяцев в Яндекс Практикуме и OTUS до года в Skypro. Нетология предлагает 14-месячное обучение с углублением в ручное тестирование, автоматизацию и нейросети. Такой диапазон позволяет выбрать формат в зависимости от целей и доступного времени.

Что конкретно умеют делать после завершения курса по автоматизации тестирования на Python выпускники профильных программ?

Выпускники осваивают написание UI- и API-тестов, создание отчетов в Allure, работу с Jenkins, Docker и CI/CD. В Нетологии студенты дополнительно учатся использовать Cypress и Playwright, а в Skillbox углубляются в DevOps-практики и архитектуру тестов.

Выбор курса: предпочесть программу с гарантией трудоустройства или сосредоточиться на содержании и уровне подготовки?

Skypro и Нетология предоставляют карьерное сопровождение и помощь в поиске работы. В OTUS и Хекслете акцент делается на практических проектах и формировании портфолио. Поэтому выбор зависит от того, что важнее — поддержка в трудоустройстве или глубина подготовки.

На каких инструментах делают упор в программах по автоматизации тестирования: Selenium, Pytest или другие решения?

Почти в каждом курсе присутствуют Selenium и Pytest. В GeekBrains+Skillbox акцент дополнен Postman, SQL и Jira. В Хекслете главными инструментами становятся Playwright и Jest, а в Нетологии изучают также Cypress и Puppeteer.

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

Да, большинство программ рассчитано на новичков. В Skypro и Яндекс Практикуме есть вводные блоки по основам тестирования и Python, а в Skillbox добавлены модули Python Basic и Advanced.

Нужен ли практический опыт ручного тестирования прежде чем переходить к автоматизации тестов ПО?

Некоторые школы начинают именно с ручного тестирования. В Нетологии и Skypro студенты сначала осваивают баг-репорты и тест-дизайн, а затем переходят к автоматизации. В OTUS требуется базовое знание Python, поэтому упор сразу делается на автотесты.

Какие карьерные возможности открывает освоение автоматизации тестирования веб-приложений?

Выпускники курсов могут претендовать на должности QA Automation Engineer или Python QA Engineer. Например, в GeekBrains+Skillbox студенты учатся работать с CI/CD и SQL, а в Яндекс Практикуме формируют портфолио из 10 проектов, что помогает быстрее выйти на рынок.

Включают ли топовые школы обучение API-тестированию в базовую образовательную программу?

Да, API-тестирование есть почти в каждом курсе. В Skypro студенты осваивают Postman и SoapUI, в OTUS работают с REST Assured, а в Яндекс Практикуме применяют Postman и Swagger.

Содержат ли современные образовательные программы модуль по работе с базами данных и изучению SQL для автоматизаторов?

Да, SQL включен в программы большинства школ. В Skillbox есть отдельный модуль для работы с базами, в Нетологии SQL используется в нагрузочном тестировании, а в Яндекс Практикуме он входит в базовую часть курса.

Какие практические работы включают в портфолио выпускники программ по автоматизированному тестированию?

Это проекты с автотестами для веб-приложений, API и мобильных сервисов, отчеты в Allure и кейсы с CI/CD. В OTUS выпускники создают собственный фреймворк, в Хекслете портфолио публикуется на GitHub, а в Яндекс Практикуме итоговый проект объединяет UI-, API- и юнит-тесты.

Профессия тестировщика-автоматизатора остается одной из самых востребованных в IT. Начинающие специалисты могут рассчитывать на зарплату от 70 000–90 000 руб., а опытные инженеры в крупных городах, особенно с навыками Python, Java и современными фреймворками, зарабатывают от 250 000 руб. и выше. Автоматизация открывает путь к стремительному карьерному росту, ведь компании ценят специалистов, которые умеют экономить ресурсы и ускорять выпуск продуктов. Выбирая курсы по автоматизации тестирования, важно обращать внимание на практическую часть, количество проектов и поддержку экспертов — это ключ к формированию портфолио и реальным навыкам, которые сразу пригодятся на рынке труда.

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

Собрали 15 наиболее эффективных платформ, которые помогают систематизировать профессиональные и личные задачи и организовать проектное управление.

Что такое таск-трекер

Таск-трекер или таск-менеджер — решения для визуализации и планирования работы. Эти платформы обеспечивают порядок и контроль рабочих процессов за счет разнообразных инструментов.

Ценность таких систем — отображение задач с четкими сроками и приоритетами.

Среди востребованных функций таск-трекеров:

• Списки задач — базовый инструмент для фиксации всех дел. Позволяет определять приоритетность и отслеживать сроки.
• Календарь — визуальное распределение задач по дням, неделям, месяцам. Облегчает создание расписаний, установку оповещений и контроль дедлайнов.

• Диаграмма Ганта — инструмент для проектного управления. Визуализирует взаимосвязи между задачами, параллельные и последовательные процессы, а также позволяет прогнозировать финальные сроки реализации проектов.

За счет этих возможностей современные таск-менеджеры превратились из простых планировщиков в полноценные системы для организации рабочих процессов любой сложности.

Кому и зачем нужны таск-трекеры

Таск-трекер — универсальный инструмент, который полезен как отдельным специалистам, так и большим командам.

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

Какие задачи решает таск-трекер:

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

Таск-трекеры пригодятся всем, кто хочет работать структурировано, быстрее достигать целей и не тонуть в хаосе дел.

Как подобрать подходящий таск-трекер

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

• Цели использования. Определите, для чего вам нужен таск-трекер —личное планирование, управление командой, контроль проектов или комплексный бизнес-инструмент.
• Функциональность. Нужны вам только списки дел или важны такие функции, как канбан-доски, диаграммы Ганта, календари, интеграции с CRM и почтой? Чем сложнее процессы, тем богаче должен быть функционал.
• Удобство интерфейса. Решение должно быть понятным и простым в работе. Если инструмент сложнее самих задач, его вряд ли будет удобно применять.
• Совместная работа. Для команд важны функции распределения ролей, уведомлений, комментариев и обмена файлами.
• Интеграции. Поддержка связки с другими сервисами (Slack, Google Drive, e-mail, CRM и др.) значительно упрощает организацию рабочих процессов.
• Стоимость. Многие сервисы предлагают бесплатные версии с базовым функционалом. Для старта этого часто достаточно, а при расширении можно перейти на платные тарифы.
• Мобильность. Удобное мобильное приложение позволяет контролировать задачи в любом месте.

Вполне возможно, что пока вы найдете оптимальный сервис, вам придется попробовать в действии несколько из них. Собрали список лучших таск-трекеров, доступных для пользователей в РФ.

Kaiten

Kaiten — цифровая платформа для планирования и контроля задач, которая подходит отдельным специалистам и компаниям любого масштаба.

Преимущества:

• Создание неограниченного количества рабочих пространств и досок.
• Визуализация данных на канбан-досках, диаграмме Ганта, календаре или таймлайне.
• Легкий перенос данных из Jira, Trello, Notion и других систем.
• Интеграция с Google Календарем, Telegram, GitHub, GitLab, Tilda и др.
• Гибкая настройка процессов любой сложности благодаря простому интерфейсу.
• Создание и совместное редактирование документов прямо в системе.
• Создание связанных задач.
• Получение детальных отчетов для глубокой аналитики рабочих процессов.
• Обсуждение задач во встроенном чате и уведомления о событиях.
• Работа из любой точки через мобильное приложение для iOS и Android.
• Оплата только за нужные функции благодаря опциональным модулям.

Недостатки:

• Обилие функций может вызвать сложности у начинающих пользователей.
• В настоящий момент ограничены возможности для кастомизации досок.

Стоимость: бесплатный план допускает создание 3 рабочих пространств и 5 досок с безлимитным количеством колонок и задач. К каждой карточке можно прикрепить только 1 чек-лист, а также создать до 5 пользовательских полей.

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

Цена расширенных тарифов стартует от 180 ₽ ежемесячно за одного участника. Они расширяют количество пространств, досок и подключаемых пользователей, позволяют просматривать углубленную аналитику и подключать дополнительные модули под нужды бизнеса (Канбан, Скрам, ГАНТ и Ресурсное планирование и другие).

Полный спектр возможностей и все модули можно протестировать бесплатно в течение 2 недель.

O!task

O!task — сервис, который можно использовать как бесплатный таск-трекер задач для команды. Разработчики регулярно дополняют его новыми функциями, и сейчас сервис предлагает набор полезных инструментов для планирования работы.

Преимущества:

• Создание неограниченного числа задач.
• Ведение учета финансовых операций с привязкой к проектам и клиентам.
• Использование гибких Agile-подходов для настройки рабочих процессов.
• Встроенный инструмент «Блокнот» для фиксации заметок и идей.
• Таймеры для анализа личной и командной продуктивности.
• Встроенные инструменты коммуникации (комментарии в задачах) и интеграция с внешними каналами (Telegram, email).
• Возможность прикрепления файлов к задачам.
• Формирование корпоративной базы знаний для обучения сотрудников.
• Обработка входящих запросов через встроенную CRM-систему.
• Совместимость с популярными сервисами (Google Docs, Figma и др.).

Недостатки:

• Для работы требуется стабильное интернет-соединение.
• Отсутствуют нативные приложения для ПК и мобильных телефонов, доступ в систему осуществляется только через браузер.

Стоимость: бесплатный план включает базовый функционал для команды до 2 человек и 250 МБ дискового пространства.

Стоимость платных подписок начинается от 399 ₽ за юзера/месяц с расширением лимитов на количество пользователей и объема хранилища. На премиум-тарифах вам доступны персональные менеджеры и техподдержка

Яндекс Трекер

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

Преимущества:

• Разные форматы досок: классический Канбан, бэклоги, спринты (особенно востребованы в IT-среде).
• Создание до 2 000 задач в рамках одной доски.
• Гибкое распределение ролей: ответственные, соисполнители, наблюдатели.
• Встроенная система комментирования и обсуждения в карточках.
• Тайм-трекинг и анализ трудозатрат.
• Группировка задач по командам, отделам или процессам.
• Система уведомлений об изменениях в задачах.
• Таймеры для оперативной обработки запросов.
• Прикрепление файлов к карточкам.
• Связи и зависимости между задачами.
• Детализированная система отчетности.
• Редактор без правки кода для персонализации рабочего пространства.
• Бесплатные обучающие материалы для новичков.
• Интеграция с сервисами экосистемы Яндекс.
• API-доступ и импорт данных из Jira, Excel и других систем.

Недостатки:

• Обязательная регистрация аккаунта в Яндексе.
• Ограниченная аналитика для Scrum и Kanban подходов.
• Лимиты на количество задач в канбан-досках
• Файлы хранятся исключительно в Yandex Cloud.
• Некоторые пользователя считают интерфейс перегруженным.

Стоимость: бесплатный план включает до 5 пользователей.

Платные подписки стоят от 449 ₽ за чел/мес (при оплате за 3 месяца). Продвинутые тарифы предоставляют увеличенный объем хранилища и количество участников в телеконференциях, архив писем и другие опции.

Для команд от 250 человек действует индивидуальное ценообразование.

Тестовый доступ длится 14 дней и стоит 1 ₽ за пользователя.

WEEEK

WEEEK — рабочее пространство, которое объединяет возможности менеджера задач, канбан-досок, CRM и базы знаний. Уникальность сервиса заключается в фокусе на недельном планировании, что позволяет концентрироваться на приоритетах и гарантировать завершение начатого.

Преимущества:

• Отсутствие ограничений на количество проектов и рабочих пространств.
• Поэтапное ведение задач (до 6 шагов) с привязкой исполнителей, сроков и меток.
• Напоминания через мобильное приложение, SMS, e-mail и Telegram.
• Встроенная система CRM для работы с клиентскими запросами.
• Мониторинг загрузки сотрудников и контроль прогресса по проектам.
• Удобный интерфейс, который легко освоить без обучения.
• База знаний с коллективным редактированием документов.
• Инструменты для применения методик тайм-менеджмента.
• Система горячих клавиш для ускорения навигации в системе.

Недостатки:

• В мобильной версии возможности урезаны.
• Диаграмма Ганта реализована лишь частично.

Стоимость: бесплатный тариф рассчитан на команды до 5 участников и включает базовый набор функций. Каждому пользователю предоставляется 200 Мб для хранения файлов.

Премиальные планы начинаются от 199 ₽ в месяц за человека. В них открывается доступ к неограниченному числу проектов и досок, истории изменений, гостевым аккаунтам и другим профессиональным возможностям.

Shtab

Shtab — многофункциональная платформа для координации коллективной работы. Сервис собирает в едином пространстве инструменты для визуализации работы, планировщик задач для сотрудников, облачное хранилище данных, трекинг временных затрат и другие полезные опции.

Преимущества:

• Настройка безлимитного числа этапов и статусов работы.
• Встроенные средства коммуникации: обсуждения, комментирование и добавление вложений непосредственно в карточках заданий.
• Контроль дедлайнов на временной шкале.
• Адаптация рабочих областей и досок под специфические бизнес-процессы.
• Инструмент приоритизации дел по методу Эйзенхауэра.
• Настраиваемые типы задач и пользовательские поля.
• Фиксация отработанного времени и оценка эффективности команды.
• Отслеживание активности участников в проектах.
• Персонализация карточек с помощью кастомизации обложек.
• Просмотр вложенных подзадач без открытия основных карточек.
• Создание баз данных с индивидуальными статусами и этапами.
• Финансовый модуль для контроля доходов и расходов

Недостатки:

• Отсутствие встроенных отчетов для канбан-досок.
• Ограниченный перечень интеграций со сторонними платформами.

Стоимость: в бесплатной версии можно подключить до 5 участников и использовать 1 Гб облачного хранилища.

Цена премиум-подписок начинается от 190 ₽ за чел/мес (при долгосрочной оплате предусмотрены скидки).

Платные тарифы включают увеличение числа участников, расширенное хранилище, автоматизацию процессов, базы данных, гостевые ссылки, продвинутый тайм-трекер, диаграмму Ганта, финансовый учет и другие функции.

Доступен 14-дневный тестовый период.

ЛидерТаск

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

Преимущества:

• Специальный маркер «В фокусе» для концентрации на ключевых задачах.
• Цифровой ежедневник с почасовым планированием дня.
• Публичные рабочие пространства для клиентов и внешних исполнителей.
• Полнофункциональная работа без интернет-соединения.
• Многоуровневая структура проектов и задач.
• Раздел аналитики с показателями продуктивности сотрудников.
• Речевой ввод задач.
• Уведомления через бота в Telegram.
• Автоматическое создание повторяющихся задач с заданным интервалом.
• Поддержка методик тайм-менеджмента (GTD, Pomodoro и др.).
• Обмен медиафайлами, документами, ссылками и комментариями в задачах.
• Напоминания о сроках выполнения.
• Регулярное резервное копирование данных.

Недостатки:

• Нет автоматической синхронизации между планировщиком и канбан-досками, возможен только ручной перенос дел.

Стоимость: бесплатно доступно до 10 проектов, 3 досок и 100 задач.

Персональный тариф «Премиум» снимает эти ограничения и добавляет 2 Гб облачного хранилища за 3199 ₽/год

Корпоративный тариф «Бизнес» рассчитан на работу команды от 2 человек и стоит 4999 ₽/год за пользователя. На этом плане можно вести совместные проекты и доски, делегировать задачи и смотреть журнал перемещения карточек.

ПланФикс

ПланФикс — платформа для организации и контроля рабочих процессов, задач и проектов в одном месте. Сервис легко подстраивается под специфику любой компании — от малого бизнеса до крупной корпорации. В арсенале есть таск-менеджер, встроенная CRM и широкий набор функций для автоматизации рабочих сценариев.

Преимущества:

• Возможность глубокой персонализации — можно создавать рабочие пространства и проекты из нескольких уровней.
• Закрепление задач за сотрудниками с быстрой передачей необходимых данных и доступов.
• Ежедневник, в котором отображаются индивидуальное расписание, просроченная работа и текущие приоритеты.
• Общение с командой прямо в задачах с функцией форматирования сообщений, вставкой ссылок и файлов.
• Планирование проектов при помощи диаграммы Ганта.
• Встроенная аналитика и создание собственных отчетов для оценки необходимых метрик.
• Единая база контактов всех физических и юридических лиц.
• Интеграции с виртуальными АТС, соцсетями, мессенджерами и другими инструментами.
• Учет финансовых доходов и расходов компании.

Недостатки:

• Некоторые пользователи отмечают устаревший интерфейс.
• Возможные сложности в освоении платформы для новичков.

Стоимость: на бесплатном тарифе можно зарегистрировать до 5 человек и использовать 1 Гб файлового хранилища.

Платные подписки предлагают расширенный объем хранилища, гостевые ссылки, массовые операции с карточками, пользовательские фильтры и многое другое. Цены тарифов стартуют от 360 ₽ за чел/мес при годовой оплате.

Полный набор функций можно попробовать без оплаты в течение 14 дней.

Pyrus

Pyrus — инструмент для структурирования бизнес-процессов, избавления от рутины и организации взаимодействия команды. Система предлагает канбан-доски, функции документооборота, средства для коммуникации и согласования работы.

Преимущества:

• Создание собственных шаблонов карточек и настройка этапов выполнения процессов.
• Настройка доступов и ролей пользователей.
• Автоматизация повторяющихся заданий и установка взаимосвязей карточек.
• Совместная работа с документами и обмен файлами.
• Встроенные комментарии по задачам и документам.
• Раздел «Входящие», куда автоматически попадают дела, требующие реакции или согласования.
• Быстрое утверждение задач в один клик с любого устройства.
• Интеграции с облачными сервисами, мессенджерами и бизнес-приложениями.
• Работа без интернет-соединения с последующей синхронизацией.

Недостатки:

• Некоторые интеграции платные.
• Функции чатов ограничены и пока не дотягивают до специализированных мессенджеров.

Стоимость: бесплатный тариф предусматривает неограниченное число участников и 1 Гб облачного хранилища.

Базовый платный пакет стоит от 415 ₽ за чел/мес при годовой оплате. Он включает возможности документооборота, набор интеграций, систему CRM и 100 Гб дискового пространства. Опция расширения хранилища обойдется в 4 000 ₽/мес за каждые дополнительные 100 ГБ.

Корпоративная версия включает локальную установку на серверное оборудование, персональное обучение сотрудников, приоритетные обновления системы, неограниченный объем хранилища и доступ к SQL-базам данных.

SingularityApp

SingularityApp — сервис для организации работы, доступный через облако на всех популярных платформах. Сервис интегрирует функции таск-трекера задач для команды и контроля персональной продуктивности в едином рабочем пространстве.

Преимущества:

• Добавление задач любым удобным способом: через e-mail, бота в Telegram, голосовые команды или виджеты.
• Возможность распечатать расписание на день и затем загрузить его обратно в систему с помощью камеры.
• Автоматическая сортировка дел и интеллектуальные фильтры для быстрого поиска.
• Режим проверки, позволяющий пересматривать и актуализировать список задач.
• Двусторонняя интеграция с Google Calendar.
• Планировщик дня с разбивкой по часам.
• Установка пароля на задачи.
• Многоуровневая структура проектов и вложенных задач.
• Поддержка техники тайм-менеджмента Pomodoro и режим фокусировки.
• Встроенный трекер привычек.
• Настройка приоритетов, тегов и повторяющихся дел.
• Система напоминаний о просроченных делах с выделением цветом.

Недостатки:

• Распределять задачи между пользователями можно только на платных тарифах.
• Нет поддержки канбан-досок.
• Отсутствует полноценный учет затраченного на работу времени.

Стоимость: бесплатный план рассчитан для пользования базовыми функциями на одном устройстве. На нем можно создать до 10 проектов, поставить всего 1 уведомление на задачу и сформировать до 3 привычек.

Платные тарифы включают расширенные инструменты: интеграцию с почтой и Telegram, совместный доступ, резервное копирование, синхронизацию между разными устройствами. Цены начинаются от 209 ₽ в месяц при годовой оплате.

После регистрации доступен триал-период с большинством функций сервиса для планирования задач.

Strive

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

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

Преимущества:

• Безлимитное количество проектов и задач.
• Гибкие форматы представления данных: список, таймлайн, канбан-доски.
• Назначение исполнителей и цветовое выделение заданий.
• Персональные списки дел для каждого участника.
• Декомпозиция крупных проектов на тематические компоненты.
• Встроенные средства коммуникации в карточках задач.
• Файловый обмен и совместное редактирование документов.
• Настройка уровней доступа и оповещений.
• Подписка на изменения в проектах.
• База регламентов и стандартов работы.
• Индикация активности сотрудников в реальном времени.
• Интеграция с внешними документами (Google Docs, Sheets, Figma).

Недостатки:

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

Стоимость: бесплатный план дает подключить до 10 участников, вести неограниченное число проектов и задач, создавать до 3 рабочих пространств. Доступен весь спектр возможностей без ограничений.

Платные версии стоят от 225 ₽ за чел/мес и снимают лимит на количество пространств, регламентов и документов. Система открывает доступ к аналитике и статистике по задачам, новым пользовательским ролям, интеграциям и другим функциям.

Есть 14-дневный пробный период.

YouGile

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

Преимущества:

• Разные режимы визуализации работы: канбан-доски, планирование при помощи диаграммы Ганта и календаря.
• Сводки задач с гибкими фильтрами.
• Обсуждение работы в каждой задаче.
• Настройка правил для перемещения задач между этапами.
• Система «зеркальных» задач с автоматической синхронизацией изменений.
• Детализированная лента активности со всеми действиями в системе.
• Персонализированная система оповещений через мобильные уведомления и электронную почту.
• Тайм-трекинг с функцией запуска таймера в карточках.
• Шаблоны задач с автоматизацией повторов.
• Интеграционные решения с Google Календарем и Slack.
• Отчетность в табличном формате с экспортом в Excel и автоматической рассылкой.

Недостатки:

• Отсутствует расширенная аналитическая система.
• Нет возможности создания базы знаний.

Стоимость: бесплатный доступ предоставляет полный набор функций без ограничений по времени для команд до 10 участников С 11 участника нужна оплата в размере 495 ₽ в месяц за человека.

Тариф «Коробка» стоит 849 ₽ за пользователя в месяц с возможностью локальной установки на сервер компании.

Премиум-тариф «Платформа» предполагает индивидуальное ценообразование, включает кастомизацию системы и готовые расширения под специфические нужды бизнеса.

Moo.Team

Moo.Team — решение, объединяющее планировщик задач для сотрудников, CRM и инструменты для коммуникации с коллегами и заказчиками.

Преимущества:

• Интеграция с Google Drive, Google Search Console, Яндекс.Метрика и другими платформами.
• Мониторинг загруженности сотрудников и их активности в реальном времени.
• Календарь планирования мероприятий, отпусков и дедлайнов.
• База паролей для безопасного доступа к данным.
• Функция скрытых от клиентов и сотрудников комментариев.
• Перенос сообщений между задачами.
• Декомпозиция больших задач на подзадачи для пошагового выполнения.
• Тайм-трекер с учетом трудозатрат и финансовых расходов на работу.
• База знаний для онбординга сотрудников.
• Персонализированные дашборды проектов.
• Автоматический расчет стоимости проектов на основе времени работы специалистов.
• Модуль для работы с фрилансерами.

Недостатки:

• Сортировка задач доступна только по спискам, созданным вручную.
• Недостаточно инструментов для аналитики.
• Нельзя выстраивать иерархию сотрудников.

Стоимость: бесплатная версия таск-трекера открывает доступ ко всем функциям системы, но позволяет подключать не более 3 пользователей и вести до 2 проектов. При этом нет лимита на количество задач, подзадач и клиентов. Объем дискового пространства — 1 Гб.

Платные подписки начинаются от 990 ₽ за 10 пользователей в месяц и расширяют количество проектов и дискового пространства.

Все тарифы можно попробовать за 1 месяц тестового периода.

Выводы

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

Несколько основных рекомендаций:

• Выбирайте инструмент под задачи бизнеса, а не наоборот. Лучше простой сервис, который будет реально использоваться, чем перегруженная система, лежащая без дела.
• Обращайте внимание на масштабируемость. Если команда растет, важно, чтобы платформа не ограничивала возможности.
• Интеграции экономят время. Чем больше привычных вам инструментов поддерживает сервис, тем меньше ручной работы.
• Автоматизация и отчетность помогают держать процессы под контролем. Эти функции особенно полезны руководителям и менеджерам проектов.
• Интерфейс важен. Даже самые продвинутые возможности бесполезны, если команде сложно ими пользоваться.

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

Именно в первые 90 дней — в период онбординга — решается, останется ли человек в компании или уйдет с формулировкой «не сложилась химия». Причем чаще всего дело не в неподготовленной технике и пропавших пропусках, а в отсутствии понятной структуры и ощущения смысла. Поэтому все больше компаний начинают относиться к онбордингу как к продуктовой задаче: прописывать рабочие процессы (workflow), автоматизировать шаги и измерять результат.

Как AI выводит автоматизацию на новый уровень

В классическом HR многое держится на чек-листах: что, кем и к какой дате должно быть сделано. В code-driven подходе все описывается как алгоритм — со сроками и условиями (например, в зависимости от того, в какую команду выходит новый человек, ему назначат разный список вводных обучающих курсов).

Современные HR-платформы уже давно предлагают готовые модули, которые берут на себя «бумажную» часть адаптации. Такие платформы собирают данные нового сотрудника, создают аккаунты и ID, назначают обучение и даже отвечают на типовые вопросы через чат-ботов.

Исследования показывают: такие решения ускоряют выход на продуктивность и снижают количество ошибок. Аналитик Джош Берсин отмечает, что в некоторых компаниях 10 HR-специалистов поддерживают более 6000 сотрудников именно за счет глубокой автоматизации процессов обучения, комплаенса и онбординга. По его прогнозу, AI может взять на себя до 50–75% процессной нагрузки HR-отдела, освобождая время для стратегических и «человеческих» задач.

Важный момент: автоматизация должна быть связана с метриками. Для онбординга это time-to-productivity — процент завершенных обучающих модулей, оценка вовлеченности или удовлетворенности менеджеров. Если этап с метриками пропущен, AI рискует остаться красивой игрушкой без бизнес-ценности.

Координация между отделами: онбординг как совместный проект

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

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

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

Онбординг в формате кода дает бизнесу возможность измерять эффективность процесса и делает его понятным для всех вовлеченных коллег. Уже упомянутая метрика time-to-productivity показывает, насколько быстро сотрудник приносит пользу; опросы фиксируют настроение и вовлеченность, подсвечивают прозрачность процессов.

Эти данные превращаются в инструмент обратной связи для HR и руководителей, позволяя вовремя корректировать процесс.

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

Представим интегрированный workflow. Кандидат подписывает оффер, и система автоматически запускает цепочку действий: IT готовит аккаунты, календарь создает встречи, новичок получает доступ на портал с FAQ и обучающими видео, а команда получает уведомления о дате выхода нового коллеги.

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

Автоматизация помогает и с точностью по времени. Подписать документы до выхода, вовремя выдать оборудование, провести оценку на 90-й день — все это критические дедлайны, нарушение которых грозит не только неудобствами, но и юридическими рисками. Хорошая система напомнит HR, если сотрудник не загрузил нужный документ, или предупредит менеджера о приближении финальной оценки по испытательному сроку.

Стоит все же отметить, что автоматизация снимает рутину, но не заменяет человека.

Чат-бот может ответить на вопрос про отпуск или дату выплаты зарплаты, но не поможет разобраться в конфликте с коллегой или справиться с выгоранием. Здесь нужен живой контакт и эмоциональный интеллект — способность услышать, поддержать, показать смысл работы. Именно поэтому баланс «код там, где повторяемо, человек там, где важна эмпатия» остается ключевым.

Не стоит забывать и про этику: в онбординге собирается множество чувствительных данных (паспортные данные, банковские реквизиты, медформы). Любой AI-инструмент должен обеспечивать прозрачность, защиту и отсутствие дискриминации в алгоритмах.

Каким будет будущее онбординга

По сути, компании идут к модели employee journey as code: от прихода до ухода сотрудника. Оффбординг тоже можно автоматизировать — закрыть доступы, вернуть оборудование, зафиксировать передачу знаний и задач. Но сколько бы ни писалось кода, только люди создают ту самую «химию» между компанией и сотрудником.

В ближайшие годы мы будем видеть больше интеграций: онбординг объединится с системами обучения, карьерного развития и сервисами поддержки благополучия. Алгоритмы смогут подсказывать, когда новичку стоит подтянуть конкретный навык, сменить проект или встретиться с ментором. Стартапы уже экспериментируют с форматом continuous onboarding — микролернинг через чат-ботов и персональные напоминания, которые сопровождают сотрудника далеко за рамками первых 90 дней.

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

Привет, меня зовут Максим Павлов, руководитель направления архитектуры в компании Axenix

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

Руководства и чертежи

BPM (Business Process Management) — это управление бизнес-процессами как системой: постановка, оптимизация, автоматизация. BPMN (Business Process Model and Notation) — язык и нотация для графического описания этих процессов.Иными словами: BPM — это методология, а BPMN — инструмент её визуализации и реализации.

BPM можно сравнить с общим руководством по сборке конструктора, в котором описываются шаги, необходимые для получения нужного результата. А вот BPMN — это как чертёж или схема конструктора, где видно, в какой последовательности соединять детали и кто за что отвечает. Такая схема помогает всем участникам понять процесс одинаково. Приведём пример с кофейней: клиент делает заказ → кассир его принимает → бариста готовит → клиент получает напиток. Всё достаточно просто. Но стоит лишь немного усложнить: добавить доставку, оплату бонусами, акции, возвраты — и без формализации уже не обойтись. Где что начинается, кто за что отвечает, что делать при исключении?

BPM отвечает на эти вопросы, превращая каждую бизнес-ситуацию в управляемый сценарий. А чтобы описывать такие сценарии, нужен универсальный язык. Таким языком стал BPMN.

Нотация BPMN появилась как ответ на потребность в схеме, одинаково понятной и бизнесу, и техническим специалистам. До BPMN в ходу были либо слишком «технические» языки вроде UML Activity Diagram, понятные только архитекторам, либо простые блок-схемы, которые не годились для автоматизации.

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

Именно это и делает Camunda — одна из самых популярных open-source платформ для исполнения процессов, описанных в BPMN.

Camunda: движок процессов нового поколения

Camunda — не просто визуальный редактор. Это полноценный исполняющий движок, который «читает» BPMN-схемы и превращает их в действия. Camunda подключается к вашей инфраструктуре и запускает процессы, отслеживает их выполнение, взаимодействует с API, ставит задачи людям и логирует все, что происходит.

На уровне архитектуры Camunda может работать в двух режимах: как отдельный сервер или встраиваемый компонент (embedded mode). Последний особенно удобен для микросервисной архитектуры — процесс запускается прямо внутри сервиса, без внешних зависимостей. При этом возможна тесная интеграция с Kafka, REST, базами данных и другими системами.

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

Два типа процессов: потоковые и пакетные

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

Потоковая обработка характерна для ситуаций, когда каждый запрос обрабатывается отдельно и в реальном времени. Например, клиент подает заявку на кредит. Система в течение 30–40 секунд проверяет данные, запрашивает скоринг, получает ответ, принимает решение и сообщает результат. Каждый запрос — это отдельный экземпляр процесса, который проходит всю цепочку действий.

Такой подход требует высокой параллельности (до 10–15 RPS), устойчивости к ошибкам, быстрой реакции. Иногда в цепочку попадают ручные этапы — например, дополнительная проверка менеджером (примерно в 5% случаев). Потоковые процессы отлично вписываются в event-driven архитектуру и легко масштабируются, особенно при использовании Kafka в качестве шины событий.

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

Такие процессы могут длиться часами, включать десятки этапов и сложную логику обработки ошибок: от откатов до компенсаций и Dead Letter Queue. При проектировании приходится учитывать параллельную обработку батчей, конфликты доступа к источникам, индивидуальные требования к формированию пакетов.Рис. 3 Суть пакетного процесса

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

В основном с помощью BPMN автоматизируются процессы, где важен порядок шагов и взаимодействие между людьми и системами. Например, обработка клиентских заявок, согласования, интеграция микросервисов и ИТ-систем и др.

Один из классических примеров — автоматизация обработки клиентских заявок в банке. Каждый клиент подает заявку, запускается потоковый процесс, система взаимодействует с внешними сервисами (скоринг, KYC, верификация), принимает решение и сохраняет результат. Весь процесс прозрачен, логируем, можно настроить алерты и отчеты для бизнес-пользователей.

Прозрачность и контроль

Одним из плюсов BPMN-систем является возможность мониторинга. Camunda предлагает встроенные инструменты (например, Cockpit), а также легко интегрируется с Prometheus и Grafana. Это позволяет DevOps-команде видеть текущую картину: сколько процессов активны, где возникли ошибки, какие этапы «висят», сколько времени занимают ключевые шаги.

Для бизнеса доступны BI-дэшборды и email-уведомления — можно получать отчеты о «застрявших» задачах, несанкционированных отклонениях и задержках. Все это повышает управляемость и доверие к автоматизации.

Оркестрация микросервисов и ML-модели

Camunda отлично вписывается в современную микросервисную архитектуру. Каждый микросервис выполняет атомарную задачу, а orchestration layer — в виде процесса BPMN — управляет последовательностью. Это снижает связность, упрощает внесение изменений и повышает надёжность.

Дополнительно, процессы могут вызывать внешние ML-сервисы — например, для скоринга, классификации, предсказаний. Camunda не ограничивает формат интеграции: это может быть REST, gRPC, Kafka: зависит от ваших технических предпочтений. Возможна реализация механизма принятия решений на лету, где модель принимает решение, а BPMN описывает, что с этим решением делать дальше.

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

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

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

Что будет дальше

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

Дальнейшее развитие BPMN-систем сегодня тесно связано с трансформацией архитектурных подходов в сторону событийной (event-driven) и облачной (cloud-native) парадигмы. Это особенно заметно на примере эволюции Camunda, где новая версия Zeebe уже ориентирована именно на такие сценарии. Если классические BPM-движки предполагали более линейное, централизованное исполнение процессов, то современный подход позволяет строить распределенные, масштабируемые пайплайны, реагирующие на события из множества источников — будь то Kafka, REST-вызовы или внутренние системные сигналы.

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

Всё это формирует тренд на low-code/no-code — попытку упростить процесс создания процессов, дать возможность бизнесу напрямую формулировать логику, не обращаясь к разработчикам. Однако на практике это упрощение работает лишь в определённом диапазоне. Как только процессы становятся сложными, с несколькими ветками, исключениями, внешними интеграциями и транзакционными требованиями — без архитектурной работы и инженерного подхода не обойтись. Low-code подходит для простых согласований и прототипов, но реальный бизнес требует устойчивых решений.

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

К тому же скрипты не просто экономят время, а снижают вероятность ошибок. Они могут помочь в регулярном копировании файлов, сборе данных или бэкапах системы по «расписанию». В общем, полезны они будут и новичкам, и опытным айтишникам.

В этой статье рассмотрим, какой язык выбрать для написания скриптов, приведём примеры простых скриптов автоматизации и сформируем список шагов для создания эффективных скриптов.

Выбор языка для написания скриптов

Выбор подходящего языка для скриптов зависит от конкретных задач, среды, в которой работает программист, и уровня его навыков. Ниже рассмотрим 3 основных языка программирования для написания скриптов.

Обзор популярных языков

Bash

Стандартный интерпретатор командной строки в UNIX-системах. Bash хорош для автоматизации задач на уровне операционной системы: управление файлами, автовыполнение заданий через cron и так далее. Bash особенно подойдёт системным администраторам и всем, кто пользуется Linux или UNIX.

Python

Один из самых универсальных языков. Python хорош своей простотой и большим количеством библиотек. Подойдёт как начинающим, так и тем, кто уже давно занимается обработкой данных или веб-скрейпингом. Python поддерживается практически всеми платформами и может решать более сложные и объёмные задачи с помощью большого количества расширений.

PowerShell

Очень известный продукт Microsoft, который хорош для SCM и автоматизации системных задач на базе Windows. У PowerShell есть один сильный плюс — интеграция со всеми возможными сервисами Microsoft (в частности и с Active Directory). Подойдёт для корпоративных проектов на винде.

Рекомендации для начинающих

Если вы только задумались о том, как автоматизировать с помощью скриптов рутину, или только начинаете погружаться в эту тему, у нас есть 5 главных советов:

• Выберите простую задачу или сценарий, который вы регулярно выполняете вручную. Это может быть отправка писем, занесение задач в трекеры, проверка кода и конфигураций — в общем, что угодно.
• Изучите основы языка, который вы выбрали для написания скриптов, чтобы лучше понять, какие есть дополнительные функции для автоматизации системных задач;
• Практика — лучший способ освоения программирования, так что не бойтесь экспериментировать с кодом (главное всегда делайте бэкап :).
• Почитайте форумы разработчиков — там вы не только сможете найти ответы на вопросы, но и почитать об опыте других программистов. Может быть, найдёте новое интересное решение?
• Всегда пишите комментарии к коду — так вы лучше будете его понимать сами, а потом сможете поделиться и кодом, и комментами с другими разработчиками, которые могут предложить, например, сократить код за счёт более простой команды.

Простые примеры автоматизации

Копирование и организация файлов с помощью Bash

Как мы уже говорили, Bash часто выбирают для написания скриптов в Unix или Linux.

Пример: у вас есть папка с разными типами файлов. Вам нужно рассортировать их в другие директории по типам.

Скрипт для автоматизации:

Шаг первый — запускаем Bash:

#!/bin/bash

Шаг второй — создаём директории для каждого типа файлов:

mkdir -p Documents Images Videos Others

Шаг третий — перемещаем файлы:

Такой скрипт проверяет MIME-тип каждого файла и перемещает его в нужную папку. При этом вручную делать ничего не нужно — просто запустить скрипт.

Автоматизация сбора данных из интернета с помощью Python

Пример: допустим, вам нужно регулярно получать последние статьи с сайта.

Скрипт для автоматизации:

Шаг первый — запускаем библиотеку BeautifulSoup:

Шаг второй — указываем нужный URL и пишем запрос:

Шаг третий — парсим статьи со страницы:

Такой скрипт отправляет GET-запрос на сайт и извлекает заголовки и краткие описания статей. А значит, с помощью этого скрипта вы сможете получить информацию о последних статьях (в формате заголовка и краткого описания) с любого сайта.

Настройка регулярных задач через cron или Task Scheduler

Скрипты созданы, всё работает правильно? Значит, можно переходить к автоматизации скриптов через планировщиков задач. В Unix-системах это можно сделать через cron, а на Windows — через Task Scheduler.

Пример настройки cron:

Откройте файл crontab командой crontab -e и добавьте строку:

0 6 * * * /path/to/your/script.sh

Так скрипт будет выполняться каждое утро в 6 утра.

Пример настройки Task Scheduler:

• Откройте Планировщик заданий;
• Выберите «Создать задачу»;
• Установите триггер выполнения задачи — «по расписанию»;
• Укажите программу или сценарий для выполнения (например, путь к Python-скрипту).

С помощью настройки планировщиков вы можете автоматизировать любую задачу. Получать последние статьи с Tproger каждый понедельник в 9 утра? Без проблем. Проверять конфигурации системы каждый день после внесения любых изменений в код? Да пожалуйста! Во всём поможет классный правильно написанный скрипт.

Ключевые шаги при написании скриптов

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

Что здесь важно:

• Определить конечную цель автоматизации;
• Собрать все необходимые данные;
• Понять, какие процессы или шаги должны быть выполнены.

Например, если вы хотите автоматизировать еженедельную отчётность через скрипты, вам нужно определить источники данных, формат готовых данных и частоту выполнения скрипта.

Следующий шаг — разработка алгоритма, пошагового плана действий для регулярного корректного выполнения скрипта. Здесь очень важно разбить задачу на более мелкие и лёгкие части: сначала вы добавляете ресурс, с которого будут «подтягиваться» статьи; далее выбираете, что именно будет приходить вам в качестве готового результата (тайтлы и саммари статей); далее указываете, в каком виде вы должны получить результат.

Подготовка алгоритма — это:

• Точное указание вводных данных;
• Разработка логики скрипта;
• Указание порядка действий внутри скрипта.

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

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

Тестирование скрипта состоит — это 3 главных действия:

• Запуск сценария на с разными наборами данных для проверки корректности выполнения;
• Поиск и исправление логических ошибок или некорректно написанных предположений в алгоритме;
• Исправление багов и оптимизация кода.

Уделите особое внимание нетипичным или редким историям, чтобы скрипт всегда работал безошибочно после отладки.

Инструменты для автоматизации разработки

Утилиты командной строки

find — инструмент для поиска файлов в структуре каталогов. Он помогает найти файлы по имени, размеру, дате изменения и другим параметрам. Например, find можно использовать для поиска всех файлов с расширением .txt, которые были изменены за последние 7 дней:

find /path/to/directory -name "*.txt" -mtime -7

grep — инструмент для поиска текстовых строк в файлах на основе регулярных выражений. Он поможет в фильтрации данных или поиске конкретной информации в больших логах:

grep "ошибка" /var/log/syslog

awk — язык программирования для обработки текстовых данных. Подойдёт для анализа и преобразования текста с данными из таблиц:

awk '{sum += $1} END {print sum}' file.txt

Библиотеки и модули для Python

Модуль os в Python помогает проводить манипуляции с файлами и каталогами, облегчает управление процессами и так далее:

shutil — модуль для проведения операций с файлами: копирование, перемещение, архивирование:

Модуль schedule поможет в планировании выполнения задач на Python. Скрипт автоматизации:

Планировщики задач

cron — системный планировщик задач для UNIX-систем, который помогает автоматизировать выполнение сценариев или команд по расписанию:

Запуск script.sh каждый день в 3 часа утра:

0 3 * * * /path/to/script.sh

Команда at нужна для одноразового выполнения задач в определённое время. Подойдёт для нерегулярных задач:

echo "python my_script.py" | at 14:00

Советы по улучшению разработки скриптов

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

Используйте логирования

Логирование — вещь важная для любого типа кода. Оно помогает понять, в каком статусе находится выполнение скрипта и помогает в поиске проблем. 3 главные плюса логирования:

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

Для внедрения логирования можно использовать встроенные библиотеки языков программирования: logging в Python или logger в Bash.

Добавьте проверки ошибок

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

• Убедитесь, что все входные данные правильно заполнены перед первой проверкой работы скрипта.
• Используйте try-except в Python или похожие блоки в других языках для перехвата и правильной обработки ошибок.
• Возвращайте коды ошибок, чтобы лучше понимать природу проблему и вам, и конечному пользователю.

Документируйте код для повторного использования

Документирование кода — это не просто «акт доброй воли» для того, чтобы другие программисты могли учиться на вашем коде; документирование очень важно для того, чтобы повторно использовать скрипт в будущем:

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

Заключение

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

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

Концепция «Инфраструктура как код» (Infrastructure as Code, IaC) наглядно воплощена в таком инструменте, как Terraform, который позволяет настраивать ресурсы, реализовывать масштабируемость и удобное управление цифровыми активами компании. При этом изменения в инфраструктуре легко отслеживаются и при необходимости тиражируются.

Еще один инструмент предназначен для автоматизации и настройки серверов и ПО — это Ansible. Система управления конфигурациями реализована на языке Python, осуществляет доставку, развертывание и обслуживание продуктов на серверах.

В обзоре подробно рассмотрим оба инструмента автоматизации инфраструктуры, оценим их преимущества и узнаем, как они работают.

Terraform и Ansible особенно хорошо укладываются в общую картину, если смотреть на них как на один из этапов DevOps-маршрута. Для этого пригодится Roadmap DevOps-инженера в 2026 году: что учить и в каком порядке.

Что такое Terraform и как он работает

Terraform — программная платформа с открытым исходным кодом, предназначенная для управления внешними ресурсами. Инструмент разработан программистами компании HashiCorp для реализации концепции IaC. Здесь используется декларативный стиль управления внешней инфраструктурой. На практике это означает, что разработчик описывает желаемое состояние инфраструктуры, а Terraform реализует конфигурационный файл в форме кода.

Использование разработчиками высокоуровневого языка HashiCorp Configuration Language для описания требуемого состояния облачной либо локальной инфраструктуры существенно упрощает управление инфраструктурой.

Чтобы понять преимущества Terraform, нужно более глубоко разобраться в концепции Инфраструктуры как кода. Она позволяет разработчикам организовать инфраструктуру таким образом, чтобы инициализация происходила в автоматическом и непрерывном режиме.

У IaC есть следующие преимущества:

• Высокая скорость. Автоматизация происходит быстрее, чем ручное управление по интерфейсу в случае, когда требуется развернуть либо подключить ресурсы.
• Надежность. Чем обширнее инфраструктура, тем выше вероятность ошибок — то есть неправильной настройки ресурсов или подготовки служб в некорректном порядке. Применение IaC исключает неправильную подготовку и настройку — все происходит именно так, как заявлено.
• Мультиоблачная поддержка. IaC поддерживает эксперименты по управлению, тестирование и оптимизацию. Простая и быстрая подготовка новой инфраструктуры позволяет вносить изменения и проверять их эффективность, не тратя на этого мно ресурсов и времени. Если результат удовлетворительный, новую инфраструктуру легко масштабировать для продакшена.

Инструмент наглядной реализации концепции IaC Terraform для декларативного управления инфраструктурой реализует все преимущества IaC. Разработчикам не придется вручную создавать сети и прочие компоненты в консоли — достаточно создать конфигурацию, где будет описано, какой они видят будущую инфраструктуру.

Это делается в текстовом формате естественным, то есть человеко-читаемым языком. Перенос управления инфраструктурой в текст — это возможность управлять исходным кодом, редактировать его, откатывать и вносить структурные изменения.

Почему разработчики выбирают именно Терраформ:

• Открытый код. Инструмент поддерживает обширное сообщество пользователей, которые постоянно создают новые плагины для этой платформы. Независимо от используемого облачного провайдера разработчики без труда найдут нужные расширения и экспертную поддержку.
• Развитие. Terraform быстро развивается, совершенствуется и улучшается. Это перспективная система, значительно упрощающая процесс управления инфраструктурой.
• Универсальность. Терраформ можно использовать в работе с любыми поставщиками облачных услуг. Аналоги предназначены преимущественно для работы с конкретными провайдерами.
• Контроль. При изменении среды инфраструктура, управляемая Terraform, заменяется новой версией, при этом старые сохраняются, чтобы в случае необходимости сделать откаты.

Модули Terraform — это компактные и наиболее востребованные конфигурации для инфраструктурных ресурсов. С помощью модулей легко автоматизировать сложные и разветвленные системы. Более того, конфигурации могут пользоваться дочерними модулями, что ускоряет разработку и делает ее более безопасной.

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

Инструмент Terraform используется для работы в команде, при этом состояние хранится удаленно, чтобы обеспечить доступ всем участникам. При совместной работе важна эффективность управления, при этом риск ошибок возрастает. При удаленном хранении состояние можно в любой момент заблокировать, чтобы избежать недостатков в управлении.

В качестве практического примера приведем алгоритм работы с облаком:

1. Подготовка облака к работе. На облачной платформе (например, Yandex Cloud) нужно подключить платежный аккаунт, чтобы оплачивать работу виртуальных машин и динамические IP-адреса.
2. Установка Terraform. Это можно сделать с официального сайта HashiCorp, выбрав версию для используемой операционной системы. Инструмент управляется с помощью пакетного менеджера.
3. Получение данных для аутентификации. Для управления структурой Yandex Cloud через Терраформ используется сервисный аккаунт, что обеспечивает гибкую настройку доступа к ресурсам.
4. Создание файла конфигурации Terraform. Создаются директории, в которых будут содержаться файлы конфигурации и все сохраненные состояния инфраструктуры.
5. Настройка провайдера. Эксперты советуют использовать наиболее позднюю версию Терраформ. Если возникнут проблемы с установкой и настройкой провайдера, можно обратиться в поддержку.
6. Подготовка плана инфраструктуры. Terraform позволяет создавать облачные ресурсы всех видов. Для этого необходимо описать набор параметров, которые определяют свойства ресурса, то есть план инфраструктуры.
7. Проверка и форматирование файлов конфигураций. Это делается, чтобы исключить ошибки в описании инфраструктуры.
8. Создание ресурсов. Заключительный этап процесса — его результатом становится список ресурсов с их текущими параметрами.

Возможность предоставлять ресурсы в нескольких облаках и развертывать функции вне серверов делает Terraform эффективным инструментом для организаций, развивающих инфраструктуру своих ресурсов.

Что такое Ansible и какие у него особенности

Ansible, как и Терраформ, — это инструмент автоматизации инфраструктуры с открытым исходным кодом. Он позволяет управлять конфигурацией, развертывать инфраструктуру и выполнять множество других задач. При этом используется максимально простой человекочитаемый формат данных YAML для постановки целей в виде плейбуков (базовых компонентов инструмента). Для работы платформы не требуется установка дополнительного ПО, она работает на языке Python.

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

Система находится в открытом доступе — разработчики могут в любой момент изучить ее код и адаптировать под насущные потребности компании. Как и Terraform, Ansible действует в концепции «Инфраструктура как код». При таком подходе работа серверов настраивается при помощи конфигурационных файлов. Данные о настройках и серверных программных средствах хранятся в специальных папках.

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

Среди других систем автоматического управления Ansible выделяется следующими особенностями:

• Декларативность. Такой подход означает, что разработчику не нужно описывать в коде действия программы напрямую, достаточно обозначить результат, которого нужно достичь. Не придется обдумывать, какими путями это будет достигнуто, что сокращает время реализации.
• Push вместо pull. Стандартная работа серверов построена на строгой иерархии — есть управляющая машина, ей подчиняются зависимые. При стандартном управлении типа pull подчиненные сервера тянут данные от главного. Ansible использует принцип push — головная машина сама продвигает информацию к подчиненным.
• Универсальность. Как правило, системы управления нуждаются в специальном окружении для работы. Ansible действует с текущим SSH-окружением, то есть стандартным протоколом для серверного управления. Инструменту не требуется специальное ПО работы.
• Простая архитектура. В системе есть основной сервер, откуда исходят команды. К серверу подключены пользователи, общая база данных и облачные системы. В главном сервере установлен API (интерфейс управления), модули и плагины, которые реализуют различные программные решения.
• Быстрое освоение. Инструмент легко освоить, у него простой код, а в случае проблем всегда можно обратиться к сообществу или подробной официальной документации на GitHub. Язык Python и формат YAML понятны, при этом дополнительные модули можно писать на любом другом языке.

Набор модулей Ansible довольно обширный — они нужны для работы с различными программными компонентами, которые задействованы на серверах. Система успешно взаимодействует с базами данных, облачными хранилищами, пакетными менеджерами и различными программами для мониторинга. Это значит, никакие специальные библиотеки для работы скачивать не придется.

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

Основной рабочий протокол Ansible — это плейбуки, то есть файлы сценариев. Разработчики пишут их в человекочитаемом формате YAML — файлы содержат сведения о том, какой результат и на каких серверах должен быть. Плейбуки — это основа Ansible, хотя элементарные задачи можно решить и без них.

Стандартный пример работы с Ansible выглядит следующим образом:

1. Разработчик заполняет файл hosts, указывает список зависимых сервисов с доменными именами либо IP адресами.
2. Указывает переменные, необходимые для подключения. Серверам могут потребоваться имена пользователей и другие данные. В режиме по умолчанию серверы связываются через SSH с помощью ключей.
3. Пишет плейбук, указывая в нем, с какими сервисами необходимо работать и что именно делать. Плейбук сохраняется в файл.
4. Разработчик отдает команду Ansible и тем самым активирует работу плейбука.

Типовые задачи решаются даже без плейбуков. Для этого используются инструменты автоматизации рутины под названием «роли». В этом случае вместо блока tasks указывается роль, то есть шаблонный список задач и переменных для них. Роли используются также, когда одинаковую задачу нужно прописать для разных серверов.

Как интегрировать Terraform и Ansible

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

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

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

Таким образом, Terraform и Ansible можно использовать совместно. Первый создает инфраструктуру, второй обеспечивает четкую и быструю настройку сетевых устройств и развертывание приложений. Ответственность разделяется по разным инструментам, при этом общая скорость и безопасность управления повышаются.

Применение в тандеме Terraform и Ansible позволяет управлять инфраструктурой приложений без ручных операций на сервере. Терраформ создаст базовые элементы, а Ansible интегрирует компоненты, которые надстраиваются на них. Связующим звеном служит статический или динамический инвентарь. В зависимости от назначения облачного сервиса и сложности проекта используются разные сценарии.

Kubernetes (или K8s) — это открытая система содержания контейнеров, которая автоматизирует развёртывание, масштабирование и управление контейнерными приложениями. Разработали её энтузиасты из Google: Джо Беда, Брендан Бёрнс и Крейг МакЛаки. А позже Kubernetes была передана подразделению Linux Foundation с открытым исходным кодом.

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

Kubernetes мониторит состояние контейнеров данных, поддерживает связи между ними или изолирует их друг от друга при необходимости. Кроме того, он следит за нагрузкой на систему и позволяет оперативно масштабировать систему. В этом и есть весь смысл определения Kubernetes как оркестратора данных: он «говорит», кому, когда и насколько «громко» нужно «играть». Каждый контейнер — это «музыкант».

Из чего состоит Kubernetes

Объясняем на примере сотрудников:

• Pod (под), сотрудник низшего звена — это наименьшая единица развёртывания в Kubernetes, которая представляет собой один или несколько контейнеров, работающих вместе. Каждый под имеет свой IP-адрес и общую файловую систему.

• Node (узел), менеджер — это рабочая машина в кластере; то, что запускает работу программ. Это может быть виртуальная или физическая машина. В каждом узле работает агент kubelet, который отвечает за управление подов на этом узле.

• Кластер, старший менеджер, состоит из одного или нескольких узлов, которые объединены для совместной работы. Кластер управляется Control Plane.

• Etcd, управляющий, — база данных, которая хранит всю информацию и зависимости, необходимые для правильной работы кластеров. Иначе кластеры будут функционировать неправильно. Именно Etcd проверяет состояние работы всех кластеров, узлов и подов для правильной и корректной работы всей системы.

• Control Plane (управляющий слой или панель управления), директор, — это интерфейс для развёртывания контейнерных приложений и управления кластером. Состоит из нескольких ключевых компонентов: kube-apiserver — интерфейс API для взаимодействия с кластером, kube-scheduler — отвечает за планирование, kube-controller-manager — выполняет разнообразные задачи контроллеров, cloud-controller-manager — интегрируется с облачными провайдерами для управления ресурсами кластера.

Различные модели развертывания обеспечивают гибкость при управлении приложениями:

• Deployment используется для масштабирования, обновления версий приложения без прерываний работы пользователей;
• StatefulSet нужен для управления состоянием приложений;
• DaemonSet гарантирует, что копия pod будет запущена на каждом узле кластера. DaemonsSet используют для сбора логов мониторинга системных ресурсов.

Kubernetes поддерживает работу и с другими системами, например, с Docker. Если коротко: Docker используется для «упаковки» приложений в контейнеры, а K8s — для управления контейнерами. Для того чтобы все приложения и зависимости работали корректно, их в первую очередь нужно правильно «упаковать» и подготовить к оркестровке — здесь и приходит на помощь Docker. Использование Kubernetes и Docker вместе позволяет разработчикам быстрее писать код, правильно его подготавливать для использования приложениями и умело управлять всеми приложениями и зависимостями в контейнерах.

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

Что такое автоматизация деплоя

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

Процесс автоматизации включает в себя работу с локальными серверами разработки и облачными платформами.

Ещё плюсы — автоматизация Kubernetes:

1. Для стандартизации процессов, которая обеспечивает стабильное поведение и открываемость приложений в разных средах;
2. Возможность легко масштабировать приложение без долгого времени на настройку.

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

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

Автоматизированные процессы исключают человеческий фактор, — здесь должна быть картинка «я что-то нажал и оно всё сломалось» :) — а это, в свою очередь, значительно повышает надёжность всей системы за счёт стандартного скрипта поведения приложений при каждом запуске.

Любые масштабы — ещё один плюс автоматизации. Добавьте новые сервера или среды без необходимости дополнительной ручной настройки.

Как настроить окружение Kubernetes для деплоя

В первую очередь (ну а вдруг вы ещё не установили K8s и Docker) — базовые рекомендации:

1. Для начала необходимо подготовить сервера. Как правило, для этого используют виртуальные машины или облачные сервисы (например, AWS, GCP). Убедитесь, что на всех узлах установлены необходимые зависимости: Docker и kubeadm.
2. Установите kubeadm, kubelet и kubectl;
3. На главном узле запустите команду для инициализации мастера узла;
4. Настройка сетевого плагина — для этого установите Flannel.

Создание и конфигурация кластера включает в себя следующие этапы:

• Подготовка серверов (обновление ОС, правильно заданное время хоста, добавление репозитория, инсталляция пакетов, необходимых для кластера, запуск Docker и kubelet, установка кластера);
• Установка мастера;
• Настройка виртуальной сети;
• Подключение вычислительных узлов;
• Управление кластером с узлов, не принадлежащих кластеру;
• Установка и получение доступа к Web-UI;
• (опционально) установка WeaveScope;
• Запуск приложения.

Подготовка приложения к деплою

Здесь обязательные шаги — это подготовка окружения (развёртывание кластера, проверка, настройка container registry), подготовка репозитория, создание набора ресурсов в Deployment, настройка Service, настройка Ingress и ввод команды «werf converge» для сборки и развёртывания приложения.

Как автоматизировать деплой с Kubernetes

1. Первый шаг — это создание Deployment манифестов. Deployment манифесты позволяют управлять репликами подов.
2. Второй шаг — автоматическое масштабирование. HorizontalPodAutoscaler автоматически увеличивает или уменьшает количество подов в зависимости от нагрузки.
3. Третий шаг — использование ConfigMaps и Secrets. ConfigMaps управляет конфигурацией приложений вне контейнеров, а Secrets обеспечивает безопасное хранение конфиденциальных данных.
4. Четвёртый шаг — настройка Service и Ingress. Service даёт стабильный IP-адрес для взаимодействия с подами, а Ingress помогает управлять внешним доступом к сервисам внутри кластера.

Какие инструменты нужны для автоматизации CI/CD с Kubernetes

• Helm упрощает управление приложениями в Kubernetes.
• GitOps c ArgoCD и Flux. ArgoCD обеспечивает непрерывную доставку через GitOps. Flux также можно использовать для GitOps’а.
• Такие инструменты, как Jenkins, GitLab CI, CircleCI можно интегрировать с Kubernetes через плагины или скрипты.

Как мониторить деплои и управлять ими

• Prometheus и Grafana используются для мониторинга состояния кластера и его компонентов.
• Elasticsearch, Fluentd и Kibana-стек обеспечивают масштабируемое логирование в Kubernetes.
• Kubernetes допускает возможность отката до предыдущих версий в случае непредвиденных ошибок при обновлении деплоя.

Всё это может звучать сложно, однако правильная настройка сервисов и инструментов при автоматизации значительно упрощает процесс ввода деплоя в продакшн.

Несколько советов для автоматизации деплоя

Корректное управление версиями и окружениями — самый важный фактор для успешной автоматизации деплоя в Kubernetes. Вот несколько советов:

• Используйте семантическое версионирование (semver) — легко контролируйте изменения: от исправления ошибок и введения новых функций до внесения значительных изменений в код.
• Применяйте неизменяемые теги для контейнерных образов — так каждый деплой будет использовать выбранную версию приложения.
• Разделяйте разные окружения (development, staging, production) с помощью namespaces — так данные будут надёжно изолированы.
• Используйте ConfigMaps и Secrets для каждого окружения отдельно.
  

Как достичь безопасности и доступности серверов х100 с помощью Kubernetes:

• Настройте роли и права доступа для пользователей и сервисов — лучше до минимально возможного уровня доступа.
• Используйте инструмент Network Policies для управления трафиком между подами внутри кластера.
• Включите PSP для контроля над тем, какие поды могут быть развёрнуты в кластере.
• Автоматизируйте масштабирование подов на основе нагрузки.
• Используйте PDBs для управления перерывами в работе приложений, например, во время обновлений.
  

Как сократить затраты на инфраструктуру:

• Устанавливайте запросы и лимиты ресурсов CPU/Memory для каждого пода. Это предотвращает неопределённое поведение при перегрузке системы.
• Настройте правила размещения подов на узлах кластера для лучшей балансировки нагрузки.
• Используйте Spot Instances для автоматизации мелких задач.
• Используйте Cluster Autoscaler для автоматического добавления или удаления узлов в зависимости от потребностей нагрузки.
  

Какие есть примеры автоматизации деплоя с помощью Kubernetes

№1 — Автоматизация деплоя для микросервисного приложения

Проект: Exerica, ИИ-инструмент для анализа финансовых и статистических документов.

Ранее использовалось: GitLab, Docker Swarm с помощью Ansible.

Проблемы: просадки производительности, сложно поддерживать много файлов и плейбуков Docker Swarm, невысокая отказоустойчивость схемы с одним входным Nginx, нет гибкости системы.

Что выбрали: self-managed Kubernetes.

Дополнительные инструменты: Helm, ExternalDNS, cert-manager

Этапы автоматизации: разработка структуры диаграмм для Helm, сборка диаграмм, создание единой конфигурации, унификация шаблонов, развёртывание релиза.

Результат: Благодаря тому, что Exerica добавила дополнительную шаблонизацию и автоматическую компоновку диаграмм, получилось выстроить непрерывный процесс развертывания в Kubernetes — и все с минимальным участием человека. Плюс появилась возможность формировать релиз из любых версий компонентов, автоматически проверять успешность развертывания и делать откаты.

№2 — Использование GitOps для управления кластерами Kubernetes

Проект: ИТМО, научно-образовательная корпорация.

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

Ранее использовалось: код в GitLab → мастер-ветка с помощью любого CI/CD инструмента → установка в кластер с помощью команды «helm install». Но схема была на самая удобная, поскольку требовала от девопсов слишком много сил и времени на управление приложениями.

Потребность в GitOps: уменьшение количества девопсов, сбор обратной связи, единый источник правды.

Этапы автоматизации: выбор в качестве GitOps-оператора ArgoCD, настройка ArgoCD, настройка Application, настройка AppProject, настройка ApplicationSet.

Результат: ИТМО свела к минимуму участие девопсов в деплое, поскольку переехали на другую методологию развертывания. С GitOps появилось дополнительное приложение, позволяющее следить за изменениями проектов в сравнении с заданными в git конфигами. Теперь гораздо проще управлять сотнями приложений в кластере.

№3 — Настройка CI/CD процесса с Jenkins и Kubernetes для крупного проекта

Проект: TestProject, платформа контроля качества с ИИ-инструментами.

Какие проблемы решает интеграция Jenkins и Kubernetes: поддержка серверов (сборки, среды тестирования, оркестровка), автоматическое развёртывание параллельных сред, естественная интеграция с процессами разработки и выпуска микросервисов.

Этапы автоматизации: установка и настройка Jenkins x Serverless, импорт существующего проекта в Jenkins (создание нового репозитория, добавление необходимых файлов для Jenkins, создание пользовательских пакетов сборки для Jenkins, выбор источника для пакетов сборки, добавление поддержки модульного тестирования), интеграционное тестирование в Jenkins с помощью API.

Заключение

Kubernetes — классное решение для оркестровки контейнеров как для микросервисных, так и для крупных проектов. А использование дополнительных решений — Jenkins, GitOps, Docker — позволяет упростить работу по подготовке и развёртыванию деплоя, а также сборку приложений.

А что вы думаете об автоматизации развёртывания Kubernetes? Поделитесь своим опытом в комментариях к этой статье — будем рады почитать вашу обратную связь!

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

Образовательные платформы реализуют разные подходы к проверке заданий по программированию. Мы рассмотрим Stepik, как одну из наиболее доступных. Она позволяет любому желающему создать свой курс и наполнить его задачами по программированию бесплатно.

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

Начнём с системы проверки заданий по программированию: как она устроена, и как можно её улучшить для целей проверки более сложных задач?

Описание стандартной схемы проверки

Механизм проверки заданий на программирование на платформе Stepik состоит из двух частей:

1. «Языки и шаблоны»;
2. «Расширенный редактор».

В расширенном редакторе автор задания должен реализовать три функции:

1. generate();
2. check(reply, clue);
3. solve(dataset).

generate возвращает список строк.

Каждая строка — это один тест, который проверяет код учащегося независимо от других. Текст строки попадает в поток ввода в начале теста.

solve(dataset) — функция, реализующая эталонное решение. В качестве аргумента dataset она получает строку теста целиком, с символами переноса строк. В качестве ответа функция должна предоставить строку эталонного ответа.

check(reply, clue) — функция, осуществляющая сравнение эталонного ответа и ответа учащегося. На вход принимает две строки. Возвращает логическое значение (True или False) в зависимости от результата сравнения. При получении на вход в качестве обоих параметров эталонного ответа должна возвращать True, иначе задача считается сломанной (то есть некорректно оценит ответ учащегося).

В простейшем варианте check фактически сравнивает поток вывода в каждом тестовом случае у учащегося и эталонной функции solve, однако, не для всех задач это приемлемо.

Например, если в задаче требуется найти площадь правильного треугольника со стороной 5, то некорректно в качестве эталонного значения использовать строку «10.825317547305483» — в зависимости от округления и порядка операций точность вычислений может быть разной. Более корректно будет привести полученный от учащегося и от эталонной функции ответ к типу float, после чего сравнить абсолютную разницу между этими числами с пороговым значением (например, 0,0000000001).

В блоке «Языки и шаблоны» фактически формируется код учащегося с помощью четырёх блоков в следующем порядке:

В данном примере python3 и kotlin — языки программирования, разрешённые к использованию учащимся. Здесь могут быть перечислены несколько языков, каждый с новой строки.

Такая реализация позволяет довольно легко создавать задания, где учащийся сам должен считать что-то из потока ввода, а ответ выводить в поток вывода (есть даже упрощённый редактор во вкладке «Тестовые данные», где задаются непосредственно строки ввода и вывода).

Какие у этого сложности

Такая схема не проверяет, как был получен ответ.

Чтобы обойти это, необходимо:

• сгенерировать уникальные тесты,
• считать их в блоке ::header до кода студента,
• вывести в блоке ::footer код, который в зависимости от состояния теста, полученного ранее, проведёт только определённые проверки.

Например, для Python: сначала проверить есть ли в пространстве local объект с именем класса, чтобы узнать, реализовал ли учащийся такой класс. После чего узнать тип этого объекта, чтобы удостовериться, что это именно класс, а не функция. И, наконец, вызвать конструктор этого класса, чтобы удостовериться, что он работает.

И только если весь этот код отработает без ошибок, можно вывести какое-то сообщение, например, «Базовая проверка пройдена».

Поскольку весь код, написанный в блоке ::header, уже выполнился к моменту начала работы кода учащегося, он может узнать обо всех проверках, которые мы там производим. Следовательно, никаких сложных проверок там делать не стоит.

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

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

Рассмотрим этот процесс на примере грейдера задачи, проверяющей реализацию на Python простого класса Heap, хранящего внутри экземпляров всего один атрибут data с типом список.

Система проверки задачи

generate

Создадим шесть простых сообщений, которые будут публичными тестами.

Остальные тесты будут приватными (для начала добавим один). Для определённости и простоты отладки поместим внутрь тестовых сообщений копию кода, который будем выполнять в тестовом сценарии.

check

Как уже было описано ранее, сравнение с эталоном в данном уроке можно проводить простым сравнением строк:

solve

Внутрь функции solve поместим эталонный класс Heap, который должен проходить все проверки.

В дальнейшем весь код мы переместим в раздел ::footer шаблона с двумя изменениями:

1. Шаблон не будет содержать эталонной реализации Heap, её должен написать учащийся.
2. Вместо return мы будем использовать print, так как по жизненному циклу код учащегося не возвращает строку, а именно выводить её в поток вывода.

Система проверки цепочек задач с постепенно усложняющимся условием

Очевидно, это необходимо для того, чтобы путём декомпозиции задачи позволить учащемуся сперва решить более простую задачу. Например, реализовать класс-заглушку, как в примере выше, и только после этого добавить в него методы, соответствующие реальной структуре данных (в нашем примере, очевидно, «куче»).

Система проверки всех задач строится по описанному выше принципу, однако наследует все тесты предыдущих задач, так как мы модифицируем и расширяем функционал одних и тех же классов.

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

Так же необходимо заблокировать возможность использования модулей стандартной библиотеки Python, реализующих функциональность «кучи», чтобы учащийся самостоятельно реализовал их. Покажем это на примере блокировки модуля heapq:

Код помещается в начале шаблона, (в блоке ::header) и выполняется до кода учащегося.

Что дальше?

Примеры описанного подхода можно посмотреть в следующих уроках:

1. на примере класса «Кучи»;
2. на примере животных (кстати, в этом курсе такой же подход во многих уроках используется для задач на написание функций).

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

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

Мы пользуемся Airflow как единой системой запуска задач

В нашем банке есть собственная платформа больших данных — DataFactory. Я уже больше года занимаюсь тем, что создаю загрузчики внешних данных для неё. До того, как я пришёл в Газпромбанк, этот процесс был неоптимизирован. Часть информации обрабатывалась Java-загрузчиками, часть — написанными на голом Python.

Сейчас мы используем Apache Airflow как оркестратор ETL-процессов, а сами процессы пишем на Python. Airflow оперирует DAG — направленным ациклическим графом, в котором описываются правила работы задач внутри одной загрузки данных. Такое решение, например, позволяет нам запускать задачи параллельно внутри кластера Kubernetes — в котором за выполнение каждой задачи отвечает отдельный k8s POD.

В основном, у загрузчиков схожие правила работы. Но для каждого требуется определенные настройки, которые в виде JSON описаны в наборе конфигурационных параметров и хранятся в Airflow Variables. Например, можно указать глубину сбора данных (в днях) и другие параметры, влияющие на выполнение DAG.

Иногда процесс нужно запускать с произвольной конфигурацией. Чаще всего на стадии финальной отладки и активного тестирования работы. Раньше в такой ситуации мы меняли значения в Airflow Variables, а затем возвращали их обратно, когда загрузчик завершал работу. Случалось, что мы забывали вернуть измененные параметры обратно, а потом искали причину некорректной работы DAG. В конце концов мы задумались, как можно легко менять значения важных переменных внутри существующего кода. И придумали!

Способы изменить конфигурацию

Встроенный редактор

В UI Apache Airflow есть свой редактор JSON. Можно залезть внутрь Airflow Variable и изменить значения там. Но такой подход не очень подойдёт, если вы хотите разово выполнить загрузку со специфическими параметрами. Airflow Variable содержит постоянные значения, которые, как правило, прописываются раз и навсегда. Когда вы что-то там меняете, то после завершения разового запуска DAG вам нужно не забыть вернуть измененные параметры обратно.

Запуск с параметрами

Apache Airflow может запустить DAG со специфическими параметрами.

Они прописываются вручную в виде нового JSON. В ходе работы загрузчика каждая задача получает доступ к этим значениям и корректирует своё поведение.

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

Хардкод

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

Наш способ оптимизации запуска DAG

Итак, есть три способа передать DAG параметры: с помощью Airflow Variable, вручную через w/ config и напрямую, указав в коде значения. Наша цель — просто и удобно извне влиять на важные для загрузчика значения. При запуске очередной задачи DAG:

• сначала посмотреть, указан ли параметр при ручном запуске;
• если нет — то попытаться найти его значение в Airflow Variable;
• иначе присвоить значение из заданных в коде значений по умолчанию.

При выполнении функции внутри работающей задачи DAG функция vars_from() сначала проверяет, был ли DAG запущен с помощью w/ config. После чего пытается найти, заданы ли ключи «count_on_page» и/или «date_from» внутри JSONа, переданного через w/ config. Если да — передаёт соответствующие значения переменным count_on_page и date_from в коде задачи.

Если в словаре w/ config искомых ключей нет, то производится попытка поиска значений ключей «count_on_page» и/или «date_from» внутри JSON из соответствующей DAG Airflow Variable.

На тот случай, если необходимых значений нигде нет, в аргументах функции vars_from() мы указали значения по умолчанию. В нашем примере это 50 и 1d, взятые из констант POLLS_COUNT_ON_PAGE и POLLS_DATE_FROM_DEFAULT.

Как работает vars_from()

Функция имеет одну внешнюю зависимость: для её реализации необходима библиотека sorcery. Она предоставляет объекту информацию, откуда его вызывают. В терминах библиотеки такой объект называется «заклинанием» (spell) и инициализируется следующим образом:

Кортеж *defaults — аналог *args, а декоратор spell помещает в нулевой элемент кортежа *defaults ссылку на frame-объект функции vars_from(). Так мы можем задать значения локальных переменных, стоящих слева от вызова функции.

Обработка ключа

На всякий случай проверка вхождения ключей реализована тремя способами: по строгому соответствию с названием переменной, по её интерпретации camel case и через псевдоним.

Здесь псевдоним маршрутизирует значение из ключа sql_injection_report_mail в переменную recipients:

Если ключ есть и в ручной конфигурации, и в базе Airflow Variable, приоритет будет отдаваться переменной, которая записана стилем snake case:

Несмотря на то что в ручном запуске есть сущность «sql injection report mail», её значение будет взято из Airflow Variable.

Ещё пример, чуть более сложный:

Теперь настройка DAG для новых задач — не проблема

Загрузчики извлекают много информации из разных мест. Мы берем данные из готовых CSV-файлов, архивов, вложений почтовых ящиков, файлы из SAMBA-папок. Проникаем в REST API за полезными JSON и XML — в общем, работаем со всей информацией, которая требуется бизнес-подразделениям банка и которую разрешает собирать наш Департамент информационной безопасности.

Решение, которое мы разработали, позволяет удобнее корректировать работу DAG, не внося изменений в код загрузчиков.

Почему все так любят автотесты?

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

На самом деле всё не так. Автотесты надо поддерживать на протяжении всего жизненного цикла, время от времени проводить аудит: это не такая уж простая работа. Кроме того, нужно понимать, когда они действительно эффективны, а когда — только навредят.

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

В каких случаях эти условия не соблюдаются?

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

Когда автотесты не нужны: рассматриваем кейсы

Главная задача автотестов — уменьшить time to market и сэкономить ресурсы команды. Разбираем сценарии, при которых это не происходит.

Пример 1. Много работы и мало времени

Возьмём какой-нибудь легаси-монолит, где работает небольшое количество тестировщиков. Есть техдолг по тестам, близится релиз, сроки поджимают, бюджет ограничен.

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

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

Пример 2. UI-тестирование

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

Допустим, появился новый раздел со схожими названиями элементов: например, строки таблицы `row`, а в новом разделе также есть таблица, и каждый элемент таблицы обретает префикс, указывающий на его логическую связь, — `content-row`, `offer-row`, `media-row`. Если команда предусмотрела такой кейс на этапе груминга, то тестировщики заранее переименовали элементы привязки либо использовали regexp для «упрочнения» тестов. Но чаще встречается ситуация, когда фичу погрумили и разработчик принимает такое решение самостоятельно, тем самым ломая автотесты. Тестировщик узнает об этом, когда тесты упадут при очередном прогоне — хорошо, если падение обнаружится утром и будет время всё исправить; гораздо хуже, когда ломается регрессионный набор, проверяющий релиз.

Поэтому проще описать сценарии и быстро пробежаться по ним руками.

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

UI — это вообще больная мозоль в плане автоматизации тестирования. Бывает и так, что на этом участке команду автоматизации распускают и усиливают команду ручного тестирования.

Пример 3. Продукты, влияющие на жизнь или безопасность людей

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

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

Был случай при разработке финтех-продукта, когда технический пользователь, созданный для тестирования, при запуске миграции для перехода на ночную смену «увидел» изменения в базе и запустил прогон тестов на «боевой» базе, создав высокую интенсивность открытия долгосрочных вкладов. В итоге ставка по вкладам снизилась: для алгоритмов приложения всё выглядело так, что слишком много людей вложили деньги. И это нанесло реальный вред бизнесу. Когда «пепел» улёгся, админский доступ в БД забрали у 90% техперсонала. Для тестирования создали обезличенную и маштабированную копии «боевой» базы, добавили окружение pre production.

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

Пример 4. Развивающийся продукт

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

А уже когда продукт перестанет развиваться и техдолг по тестированию будет закрыт, можно будет оставить одного автоматизатора для поддержания и аудита автотестов.

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

Пример 5. Редкие сценарии пользовательского поведения

Этот вид тестирования иногда называют monkey testing — когда мы тыкаем во всё подряд и пытаемся создать абстрактную модель поведения пользователя. Вероятно, менее 1% людей будут себя в продукте так вести, но при этом иногда вскрываются какие-то критические сценарии, которые могут систему пошатнуть.

Такой тест актуален для любых сайтов и приложений, где можно вводить данные. Поля для ввода данных уязвимы для атак типа SQL-Injection. Кроме того, многие системы не предусматривают сценариев на случай ввода в поле отрицательных, дробных, непрописных символов — в итоге сервис, обеспечивающий обработку бизнес-логики, может запросто зависнуть.

В 2015 году я занимался тестированием крупной интернет-площадки. В обычную строку для поиска типовой заглавной страницы был помещён текст `DROP Table USERS`— и в результате все существующие пользователи были удалены. Строка поиска товара формировала запрос напрямую в базу и не была экранирована. После этой ситуации пользователей восстановили, разослали письма с извинениями, а в структуру добавили слой, проверяющий запрос на адекватность перед передачей в базу данных.

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

Почему автотесты не станут панацеей

Автотесты полезны и удобны на определённых участках работы, но не универсальны. Это как с пресловутым ChatGPT, который сам создаёт код, который в итоге надо приводить к нормальному состоянию — что по трудозатратам равно написанию с нуля.

Когда погружаешься в автотестирование, понимаешь, что нет-нет, а надо, чтобы твою спину прикрыл ручной тестировщик. Как бы ни хотелось, чтобы процент тестов выглядел 70 автоматизированных на 30 ручных, золотая середина — 50 на 50 либо 60 на 40.

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

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

Повторим: когда автотесты не нужны

• сроки и бюджет проекта ограничены: проверить руками получается дешевле экономически;
• речь идёт о развивающемся продукте с большим количеством изменений;
• тестируются продукты, где действия пользователя в системе могут принести значимый негативный эффект (здоровье, финансы, безопасность и так далее);
• тестируется фронтенд, элементы в котором могут динамически меняться;
• проверяются редкие пользовательские сценарии;
• команда не сформирована — мало тестировщиков, много разработчиков;
• автотесты не ревьювятся (код сомнительного качества), как результат — околонулевая эффективность;
• недостаточная погружённость в продукт, например, когда на проекте новый тестировщик;
• не выстроен процесс тестирования — нет понимания, что делать с автотестами дальше;
• отсутствует инфраструктура — не настроен CI/CD, автотесты запускаются руками;
• очень долгий прогон тестов с низкой результативностью (наследие предыдущего тестировщика);
• нет автоматической обработки результатов, из-за чего результаты тестов неинформативны;
• сервис или приложение написаны на редком языке, например, Cobol;
• продукт — десктопное приложение, здесь на первых порах проще делать тесты руками.

В статье команда IT-компании MediaSoft разобралась, в чем разница между этими видами тестирования, какие этапы и виды функционального тестирования, какие инструменты пригодятся, и как можно автоматизировать тестирование. А также поделилась советами для новичков в QA.

Функциональное тестирование — вид тестирования, при котором проверяем ЧТО делает программный продукт. Например, проверка API, базы данных, пользовательского интерфейса, функциональности тестируемого продукта. Проверяется на соответствие спецификациям, бизнес-требованиям. Основано на требованиях клиента.

Нефункциональное тестирование — вид тестирования, при котором проверяется КАК работает программный продукт: производительность, масштабируемость, нагрузка, UX и т.д. Основано на ожиданиях клиента. Пример: авторизация произошла за 2 секунды.

Отличия функционального и нефункционального тестирований

При функциональном тестировании:

• Мы проверяем, что система выполняет те задачи, которые были заявлены в требованиях к приложению;
• Обычно выполняется с использованием тест-кейсов, которые описывают шаги для проверки функций продукта;
• Проще провести проверку, не прибегая к использованию дополнительных инструментов.

При нефункциональном тестировании:

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

Этапы функционального тестирования

1. Определить и проанализировать, какую функциональность необходимо протестировать. Перед началом необходимо изучить тестируемый функционал: какие у нее требования, как она должна работать, как пользователь будет её использовать.
2. Написать тест-кейсы. В них тестировщик пошагово описывает сценарий проверки определенной функциональности.
3. Подготовка тестовых данных. Для тестирования используются данные, которые максимально приближены к тем, что могут использовать пользователи. Сбор тестовых данных основывается на требованиях.
4. Проведение тестирования. Происходит сравнение фактического результата и ожидаемого.
5. Составление отчета по результатам тестирования. По завершении тестирования необходимо собрать отчет с результатами прогонки тестов, списком багов и рекомендациями по улучшению продукта.

Виды тестирования, применяемые при функциональном тестировании

• модульное тестирование — выполняется разработчиками на этапе разработки приложения. Цель модульного тестирования заключается в проверке работы отдельной функциональности.

• интеграционное тестирование — проверка того, что модули работают корректно как группа. Тестирование интеграции очень важный этап, так как модули могут быть созданы разными разработчиками.

• системное тестирование — проводится на полноценной и полностью интегрированной системе для подтверждения, что система работает согласно исходным требованиям.

• регрессионное тестирование — проводится после того, как в приложение были внесены какие-либо изменения. Этот вид тестирования важно проводить, так как любые изменения могут затронуть или сломать уже существующий функционал.

• sanity тестирование или санитарное тестирование — очень похоже на регрессионное. Оно проводится, когда тестировщик получает новую сборку с минорными изменениями. Разница между этими двумя видами заключается в том, что если при регрессе мы проводим полное тестирование приложения, то при санити мы тестируем какую-то одну функциональность.

• smoke-тестирование или дымовое тестирование — проводится для того, чтобы убедиться, что наиболее критичный функционал приложения работает так, как должен.

Инструменты для ручного функционального тестирования

Системы управления тестированием:

• TestIT — система управления тестированием, которая была создана тестировщиками для тестировщиков. С её помощью удобно хранить тест-кейсы, составлять тест-планы, создавать прогоны и управлять ими.

• TestRail — удобно создавать чек-листы, тест-кейсы и прогоны, выгружать результаты прогонов, отчеты о тестировании и сами тест-кейсы в формат CSV. Также сравнивать результаты нескольких прогонов. Он поддерживает интеграцию с различными баг-трекинговыми системами (Jira, YouTrack и т.д.).

• Allure — с его помощью удобно управлять ручным и автоматизированным тестированием. Легко разрабатывать тест-кейсы и чек-листы, создавать тестовые прогоны и собирать статистику по результатам тестирования.

Инструменты для работы с БД:

• DBeaver — универсальный инструмент для управления БД с удобным интерфейсом. С помощью него можно работать с различными СУБД: MySQL, PostgreSQL, SQLite, Oracle и другими.

• SQL Developer — графический интерфейс для работы с БД и выполнения SQL-запросов. С его помощью можно создавать и выполнять запросы, исследовать базы данных и отслеживать ошибки.

• HeidiSQL — графическая оболочка для работы с MySQL, PostgreSQL и Microsoft SQL Server. Она может быть использована для создания, изменения и удаления таблиц, вставки и удаления данных, создания SQL-запросов и многого другого.

Инструменты для тестирования API:

• Postman — с его помощью можно составлять и отправлять запросы, собирать коллекции и делиться ими с коллегами. Также в Postman можно писать автотесты для тестирования API.

• SoapUI — с помощью данного инструмента можно легко и удобно тестировать как SOAP, так и REST-сервисы. Можно проверять работоспособность веб-сервисов, устанавливать доступность, работу различных запросов и отслеживать получение ответов.

• Swagger UI — инструмент для описания и проверки API-методов. К каждому запросу есть пример ответа и описание приходящих в них параметров. Не требует установки на устройство пользователя.

Системы логирования:

• Kibana — инструмент визуализации и анализа данных в реальном времени, отслеживания трендов и прогнозирования будущих событий.

• Graylog — система для сбора, хранения, мониторинга и анализа логов из различных источников в режиме реального времени. Позволяет сохранять большие объемы логов и анализировать их, используя поисковые запросы и фильтры.

• Android Studio и Xcode — можно собирать логи с мобильных устройств — Android и Xcode соответственно — в режиме реального времени. Удобно собирать, читать и анализировать логи.

Фермы устройств:

• Android Studio — с помощью инструмента Android Virtual Device Manager можно создавать и управлять виртуальными устройствами с операционной системой Android. При эмуляции устройств есть возможность протестировать приложение в различных состояниях (медленное подключение к интернету, прерывания, маленький объем памяти устройства и т.д.).

• Xcode — в данном инструменте есть возможность симуляции различных устройств Apple от iPod до Apple TV. В отличии от эмуляции с помощью Android Studio, Apple Simulator имитирует лишь часть функциональности физического устройства.

• BrowserStack — это сервис для тестирования веб-сайтов и мобильных приложений на различных устройствах и браузерах, без необходимости устанавливать их на локальном компьютере. Он предоставляет обширную коллекцию реальных устройств, операционных систем и браузеров, которые могут быть использованы для тестирования веб-сайтов и мобильных приложений на реальных устройствах в режиме онлайн.

Можно ли автоматизировать функциональное тестирование и для чего

Со временем функционал приложения растет, соответственно, количество функциональных тестов увеличивается. В этом случае на помощь приходит автоматизированное тестирование.

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

Существует много инструментов для автоматизации функционального тестирования. Про самые популярные мы поговорим ниже:

• Selenium — один из самых популярных инструментов для автоматизации тестирования веб-приложений. Selenium позволяет работать на различных операционных системах (Windows, Mac, Linux) и браузерах (Chrome, Firefox и т.д), поддерживает различные языки для написания скриптов.
• Appium — это кроссплатформенный инструмент для автоматизации тестирования мобильных приложений (нативные, гибридные и веб). Позволяет создавать и запускать тесты на реальных устройствах и эмуляторах, использовать различные языки программирования для написания тестов.
• Katalon Studio — инструмент для автоматизации API, веб, десктоп и мобильных приложений. Для написания тестовых скриптов используется язык программирования Java или Groovy. Плюс данного инструмента — для работы с ним достаточно начальных знаний языков программирования. Благодаря чему он отлично подходит для новичков.

• Ranorex Studio — еще один универсальный инструмент для автоматизации тестирования. Этот инструмент, как и предыдущий, хорошо подойдет для новичков, так как поддерживает возможность создания тестов без написания кода.

В заключение

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

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

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

Отдельный важный вопрос, который нужно решать команде тестировщиков – писать ли код, или использовать специализированные решения без кодирования.

Разобраться в этих нюансах помогает ведущий специалист-тестировщик компании IT_One Алексей Антонов.

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

• Какие цели мы преследуем?
• Что именно мы будем тестировать?
• Какие виды и уровни тестирования будем применять?
• Какое тестовое окружение нам понадобится?
• Кто будет этим заниматься?
• Когда необходимо планировать мероприятие по тестированию?
• Какие существуют ограничения на объем выполняемых работ?

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

Стратегия автоматизации тестирования

Определение цели тестирования – наша первоочередная задача, которая поможет выбрать виды тестирования из большого количества возможных. Например, если мы имеем дело с системой интернет-магазина, для нее важно обеспечить возможность совершения покупок (здесь подойдет функциональное тестирование), стабильность, скорость и масштабируемость обслуживания (тестирование производительности), скорость внедрения новых идей в систему (регрессионное тестирование), безопасность покупки (тестирование на проникновение или тестирование безопасности), соответствие стандартам и законодательным нормам.

На этапе формирования перечня объектов тестирования нам нужно понять, из чего наша система состоит, видеть ее логическую архитектуру, получить спецификацию или набор требований к системе. В нашем примере с интернет-магазином пользователь обращается к сервису через веб-интерфейс или с помощью мобильного приложения; имеется сервер приложений, с которым происходит взаимодействие по протоколу HTTP/HTTPS на базе REST архитектуры; в базе данных накапливается информация о покупках, платежах и прочих операциях пользователя; интеграция с какой-то внешней системой позволяет магазину выполнять доставку товара, проводить платежи и т. д.

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

Собрав, таким образом, объекты тестирования согласно целям, мы оцениваем, какие виды тестирования можем применить для каждого из них. В зависимости от уровня, на котором находится объект тестирования (модуль, интеграция модулей, система целиком, межсистемная интеграция, сквозной бизнес-процесс) мы определяем необходимый и достаточный объем тестирования для достижения целей тестирования.

Автоматизировать или нет?

Теперь перед нами встает задача: какую часть процесса тестирования мы можем автоматизировать. При этом мы учитываем следующие факторы:

• целесообразность – например, период окупаемости, возврата инвестиций;
• необходимость автоматизации – в некоторых случаях без нее просто не обойтись, например, если мы следуем определенным стандартам разработки в компании;
• обязательность автоматизации – например, в автомобильной промышленности для компонентов систем беспилотного вождения обязательно требуется полное покрытие кода модулей юнит-тестами;
• ограничения ручного тестирования – не все протоколы можно протестировать вручную в разумный срок) и автоматизированного – не всё можем автоматизировать с помощью доступных инструментов, или это будет очень долго и дорого.

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

Можно выделить ряд проектов, в которых автоматизация всегда оправдана:

1. долгосрочные проекты с частыми изменениями;
2. проекты с высокими требованиями по безопасности;
3. проекты со сложными вычислениями, фильтрацией данных;
4. тестирование сборки и установки;
5. протоколы, API и интеграции;
6. высоконагруженные системы;
7. проекты с высокими требованиями к качеству разработки.

Наоборот, автоматизация окажется излишней в небольших коротких проектах без поддержки (PoC, демо) и в проектах с небольшим количеством итераций тестирования.

Выбор инструментов тестирования

Определившись с задачами, объектами и форматом тестирования, мы можем построить решение по автоматизации, подобрав необходимые инструменты и сформировав фреймворк автоматизации. Я бы описал инструмент автоматизации как некий «черный ящик», обладающий функционалом написания и предоставления скриптов, умеющий воспроизводить эти скрипты, а также принимать некие тестовые данные и управлять объектами тестирования, проводить необходимые проверки и выдавать результаты в виде отчета.

Вернемся к нашему примеру с интернет-магазином и первому объекту тестирования: интерфейсу пользователя. Мы берем конечный интерфейс взаимодействия пользователя с нашей системой и начинаем подбирать наиболее подходящий инструмент, обращая особое внимание на то, насколько стабильно он распознает и умеет управлять элементами интерфейса. В итоге это могут быть такие программные продукты, как как Unified Functional Testing (UFT), Katalon Studio, Test Complete, Ranorex или программные библиотеки Selenium, Appium и аналогичные им.

Аналогично мы выбираем инструменты для других объектов с учетом их специфики. Например, для тестирования автоматизации API приоритет отдается поддержке нужных протоколов взаимодействия, а для тестирования хранилища данных – работе инструмента с СУБД.

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

Кстати, некоторые инструменты являются полноценными платформами, и с их помощью можно подвергать тестированию несколько объектов сразу. Также они могут быть интегрированы с системой управления тестированием.

Открытый код, проприетарный продукт или собственная разработка

Отдельно стоит упомянуть о разделении инструментов тестирования на категории по типу разработки:

1. решение на базе Open Source-элементов;
2. коммерческое (проприетарное) решение;
3. внутренняя разработка.

Каждая категория имеет свои преимущества и недостатки.

Так, продукты на базе Open Source, как правило, хорошо решают свои специализированные задачи, поддерживаются большим комьюнити (где можно найти ответы даже на те вопросы, которых нет в документации), обладают гибкостью разработки. Успешные Open Source проекты активно развиваются, при этом нам никто не мешает вам при наличии соответствующей экспертизы создать отдельную ветку и дописать в ней функционал, которого этому инструменту не хватает. В то же время такие инструменты требуют интеграции в комплексное решение по управлению тестированием, определенной квалификации ИТ-специалистов, а также имеют риск прекращения разработки или поддержки.

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

Внутренняя разработка – самописный инструмент, который максимально подходит под объект тестирования: мы изначально знаем, что хотим от него получить. При этом мы обладаем максимальной экспертизой по этому инструменту внутри команды и имеем возможность в какой-то момент выпустить его в Open Source. Однако для создания такого решения требуется высококвалифицированная команда разработчиков и/или инженеров по автоматизации. При его использовании мы так же можем столкнуться с низкой скоростью поддержки и ограниченной экспертизой.

Так ли надо писать код

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

Менеджер продукта, аналитик, тестировщик – создают тесты, определяют наборы тестов с приоритетами, пишут некие скрипты для автоматизации, запускают автотесты, анализируют результаты. В целом они формируют требования к автоматизации тестирования, так как являются основными пользователями.

Автоматизатор функционального и регрессионного тестирования – на его плечи ложится поддержка и развитие фреймворка автоматизации, обучение и поддержка пользователей-тестировщиков\поддержка инфраструктуры тестирования.

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

DevOps инженер – помогает как разработчикам, так и тестировщикам, а также автоматизаторам в поддержке и развертывании сред разработки и выполнения автоматизированного тестирования.

Итак, писать код стоит:

• когда в команде наработана экспертиза автоматизации, разработчики и тестировщики имеют определенный опыт;
• когда возникает сложность с приобретением коммерческих лицензий (причинами могут быть, например, бюджет или сроки на внедрение и обучение пользователей);
• когда нет готовой интеграции с инструментами управления тестированием или с другими компонентами существующего фреймворка;
• когда необходимо поддерживать низкие уровни тестирования.

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

Введение

AMQP (Advanced Message Queuing Protocol) — открытый протокол прикладного уровня для передачи сообщений между компонентами системы. Идея в том, что отдельные подсистемы или независимые приложения могут обмениваться произвольным образом сообщениями через AMQP-брокер, который осуществляет маршрутизацию, возможно гарантирует доставку, распределение потоков данных, подписку на нужные типы сообщений.

AMQP основан на трёх понятиях:

Сообщение (message) — единица передаваемых данных, основная его часть (содержание) никак не интерпретируется сервером, к сообщению могут быть присоединены структурированные заголовки.

Точка обмена (exchange) — в неё отправляются сообщения. Она распределяет сообщения в одну или несколько очередей. При этом в точке обмена сообщения не хранятся.

Очередь (queue) — здесь сообщения хранятся до тех пор, пока не будут забраны клиентом. Клиент всегда забирает сообщения из одной или нескольких очередей.

Producer — клиентское приложение, которое публикует сообщения в exchange.

Consumer — клиентское приложение, которое получает сообщения из очереди.

По сравнению с HTTP, у систем, построенных на очередях сообщений AMQP, есть ряд преимуществ и недостатков.

Плюсы HTTP

• Отладка HTTP-запросов проще, чем в AMQP. Подключаться к очереди сообщений в AMQP придётся только через сторонние утилиты, тогда как HTTP можно отлаживать прямо в браузере.
• Это популярный протокол — его используют практически всегда и везде, а значит и понимает его гораздо больше людей.

Плюсы AMQP

• Надёжность доставки сообщений реализуется «из коробки» — значит не нужно об этом волноваться. Сообщение, которое будет отправлено в AMQP-брокер, будет доставлено и обработано одним из обработчиков очередей AMQP.
• Broadcast — функционал, который позволяет уведомить разные компоненты системы в рамках одного сообщения. Таким образом, можно сократить количество отправляемых сообщений в единицу времени.

Коротко о RabbitMQ и RPC

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

RPC (Remote Procedure Call) — один из шаблонов взаимодействия в распределённых приложениях. Этот протокол позволяет программам вызывать функции и процедуры удалённо таким образом, как будто они представлены локально.

Совмещая RPC и RabbitMQ, мы в итоге получаем отказоустойчивую, распределённую систему для простого вызова функций и последующего агрегирования результатов.

Тестирование AMQP

Существуют разные способы тестирования приложений, основанных на протоколе AMQP. Вот несколько их них:

• Функциональное тестирование;
• Ручное тестирование;
• Автоматизированное тестирование;
• Интеграционное тестирование.

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

Ручное тестирование — проверка всех компонентов или отдельной, в частности, непосредственно человеком, вручную.

Но для автоматизации рутинных действий, проводимых человеком, существует автоматизированное тестирование — когда все действия, проводимые для тестирования системы человеком, описаны процедурно и могут исполняться автоматически.

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

Автотесты на Python

На мой взгляд, самый удобный способ тестировать API и MQ-сервисы — с помощью языка программирования Python, а также нескольких библиотек, о которых расскажу подробнее далее.

Основным инструментом при разработке автотестов будет pytest — библиотека с простым интерфейсом для написания тестов.

Для подключения к RabbitMQ есть множество библиотек, самая распространённая и хорошо документированная — pika.

Устанавливается всё с помощью утилиты pip:

Далее, представим, что у нас есть сервис, который работает по протоколу AMQP и непосредственно через RabbitMQ, в интерфейсе которого реализована простая функция, возвращающая последнее число из последовательности Фибоначчи:

Данный сервис подключается к RabbitMQ, создаёт очередь rpc_queue, из которой принимает сообщения, где тело запроса — это число N, от которого нужно вычислить последнее число из последовательности чисел Фибоначчи.

Основная идея при тестировании сервисов, которые работают на внешнем источнике данных (в данном случае, очередь сообщений RabbitMQ) — реализация клиента к данному источнику данных, эмулируя ввод пользовательских данных.

Напишем клиент, который взаимодействует с нашим сервисом с помощью очереди сообщений через RabbitMQ:

В данном примере:

• Устанавливаем соединение к RabbitMQ и подключаемся к очереди rpc_queue;
• Подписываемся на очередь, в которую возвращаются ответы от сервиса при вызове RPC-методов;
• Реализуем функцию on_response, которая проверяет каждый ответ и сверяет correlation_id с тем, который мы отправили. Если идентификатор ответа совпадает — это ответ конкретного запроса, и функция сохраняет ответ в self.response.

Далее мы реализуем автотесты к нашему сервису. Создадим папку tests и в ней файлы conftest.py и test_fibonacci_rpc.py:

Файл conftest.py содержит в себе всевозможные надстройки для pytest. В частности, добавим наш клиент туда для того, чтобы его можно было переиспользовать во всех подтестах, не импортируя вручную. Наш клиент будет иметь свойство Test Fixture — это объект, который можно рассматривать как набор условий, необходимых тесту для выполнения. Например, зачастую фикстуры создаются, чтобы генерировать какие-то данные ещё до теста и возвращать их для использования в тесте.

Таким образом, наша фикстура fibonacci_rpc может переиспользоваться во всех тестах как аргумент к каждой тестовой функции.

Файлы с префиксом test_ — это файлы, в которых непосредственно реализованы сами тесты. Напишем несколько тестов, которые проверяют реализацию RPC-метода fib с нашими пользовательскими значениями.

Содержимое файла test_fibonacci_rpc.py:

Функции с префиксом test_ означают, что это тестируемые методы, которые запускаются с помощью pytest.

Наш пример в test_fibonacci реализует проверку метода fib на стороне сервиса с положительными аргументами. Директивная assert проверяет условие, выполняющееся в её блоке на True или False. Если условие не выполнилось, тест упадёт с ошибкой, уведомив нас о некорректной работе сервиса.

Пример в test_non_number реализует проверку того же метода fib, только с заведомо некорректными входными параметрами. При вызове такого метода должна произойти ошибка. Если её не произошло, то мы закончим проверку метода с текстом fib must consume only ints.

Таким образом, мы полностью покрыли тестами функцию в нашем сервисе.

Заключение

В статье мы рассмотрели протокол AMQP и его частную реализацию RabbitMQ, реализовали тестовый сервис, реализующий простой удалённый вызов процедур с одним методом, а также протестировали работоспособность нашего сервиса с помощью автотестов, написанных на Python с помощью pytest.

Особенность тестирования сервисов, которые работают на протоколе AMQP, это корректная реализация объекта, который будет эмулировать запросы клиента. Для этого нужно знать некоторые особенности работы самого протокола AMQP, а также нюансы, которые использовали при разработке тестируемого сервиса (название очередей, публичные RPC-методы и прочее).

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

Как мы пришли к нынешнему устройству системы

Большинство сотрудников проходит три стадии принятия при такой ситуации.

• Отрицание — не может быть, что кто-то в 2023 ещё работает на системе, написанной на Delphi?
• Гнев — почему то, что мне нужно, работает, только если обладаешь тайными знаниями?
• Принятие — система работает стабильно, большинство доработок можно сделать достаточно просто — и уже понятно, как их проверять.

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

Сначала мы привели филиалы к единому виду, создав единую клиентскую и серверную часть. Наша команда разработки проанализировала все существующие процедуры и отчёты и объединила их в эталонный код. Мы выровняли ландшафт, мигрировали данные. Раньше было 14 баз, доработки по которым ставились независимо друг от друга.

После этого наладили CI/CD процесс. Все внутренние доработки по системе теперь обязательно ставятся через Git. До этого разработчики на все филиалы ставили доработки руками, что отнимало много времени и увеличивало количество ошибок и расхождений в разных базах.

В дополнение к существующим сложностям у системы есть особенность: доработки идут как от вендора, так и от внутренней команды разработки. Таким образом, внутренние обновления ставятся через Git On Demand по готовности, а доработки вендора также через Git, но в рамках релизов.

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

Как мы выстроили процесс автоматизации

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

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

1. Ускорили проведение проверок.
2. Упростили автоматизацию, так как изменения от кейса к кейсу незначительные.
3. Повысили мотивацию команды, так как они стали тратить меньше времени на рутину.

Далее для облегчения процесса автоматизации подробно описали тест-кейсы с шагами, без ветвлений. Хорошо описанная тестовая модель полезна не только для автоматизации, но и в целом для качественной оценки количества работы, выполняемой командой.

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

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

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

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

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

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

Какие инструменты мы используем

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

Вот что мы выбрали для себя.

Micro Focus Unified Functional Testing

Позволяет определить объекты на форме десктопного приложения: окно, radio-button, выпадающий список, поле для ввода. На основе этого к добавленному в библиотеку объекту можно применить то или иное действие: нажать на кнопку или закрыть окно.

Помимо этих инструментов на рынке есть и другие, например:

• Zeenyx,
• Winium,
• Katalon Studio,
• Test Complet Desktop.

Можно выбрать тот, который подходит именно вам.

Pywinauto

Это open source библиотека для автоматизации десктопных GUI приложений на Microsoft Windows. Он нужен для ряда проверок, например, для операций с длительным ожиданием.

Тестирование на PyTest

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

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

Python + PyTest позволяют достаточно легко это сделать. А также дают возможность встроить в пайплайн запуск в момент изменения сервиса или связанной процедуры.

Git и TeamCity

Для поддержания версионности и развёртывания кода. Как единый стандарт в банке. Автотесты мы ведём там же, что упрощает выстраивание общего процесса.

Использование ранее написанных процедур при подготовке данных

Руководствуясь лучшими практиками, мы определили, что тест должен сам себе готовить данные, чтобы работать стабильно. При участии разработчиков мы разработали ряд процедур, которые позволяют сгенерировать синтетические данные. Это помогает существенно сократить время на подготовку тестовых данных, стабилизировать и ускорить время выполнения тестов.

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

Лучшие практики, чтобы выстраивать CI/CD на десктопе

Тестирование — важная часть CI/CD-процесса, который постоянно совершенствуется. Всегда можно найти более эффективные практики, которые помогут избежать проблем в будущем. Вот ещё несколько принципов, которые помогают улучшить этот процесс.

• Должно быть версионирование кода. Если сейчас у вас этого нет, нужно начинать делать шаги к этому.
• Версионирование кода касается в том числе автотестов.
• Подробно описывайте тест-кейсы, это помогает как с погружением новых сотрудников, так и с написанием автотестов.
• Учитывайте техокна на интеграционных стендах. Если доставлять обновления, не обращая на это внимание, можно помешать другим командам работать. Если в моменте кто-то незапланировано что-то поставит, всё зависнет или вообще сломается.
• Используйте Feature toggle. Он помогает безболезненно поставить доработки на пром, даже если они не работают с включенным toggle.
• Пишите тесты, а лучше автотесты, до того, как доработку передали в тестирование. Писать тест-кейсы, когда доработки уже готовы, — это плохая практика, можно нахватать проблем, например, не хватит сотрудников, чтобы провести тестирование.
• Чем раньше привлекается тестирование, тем лучше. Ведь уже на этапе прочтения ТЗ можно увидеть слабые места, задать вопросы, исправить их и сделать сразу правильно.

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

• коробочные системы с банковской кастомизацией;
• системы, которые разрабатывают вендоры, передавая готовые дистрибутивы;
• системы, разработанные внутри банка.

Одни из них используются десятилетиями, другие — только внедряются.

Из-за этого разнообразия и CI/CD-пайплайны могут сильно отличаться. И обновлять системы вручную — или даже автоматизированно, запуская вручную только обновления отдельных систем, — долго и накладно. Чтобы сделать этот процесс эффективным, нужно научиться обновлять среды полностью автоматически. В этом помогает грамотная автоматизация.

Что нужно знать, чтобы автоматизировать обновление среды

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

Во-первых, нужно формализовать информацию об инфраструктуре в CMDB (Configuration Management Database): базы данных, сервера, тестовые среды. Главное — прописать чёткий список систем — конфигурационных единиц (КЕ), — с указанием, в каких тестовых средах они находятся.

Каждая КЕ должна иметь чёткие границы, чтобы не возникало перекрытий или пропусков отдельных компонентов. А каждая тестовая среда — конкретный состав и версию релиза, которому она соответствует в данный момент. Версии всех систем должны этому релизу соответствовать.

Чтобы сделать информацию о тестовых средах, системах и версиях более доступной мы сделали специальный сервис «Версии систем». Он автоматически собирает информацию о версиях тестовых сред и систем для отображения или предоставлении по API.

Во-вторых, нужно понимать какие системы должны быть обновлены в каждом релизе. Если в каждом Jira-эпике разместить информацию о системе и релизе, в который входит задача, то можно автоматически собрать список всех систем, которые меняются в релизе.

Мы сделали небольшую доработку Jira. И теперь при создании запроса на обновление среды автоматически создаются отдельные запросы на обновление каждой системы, которая поменялась в релизе и присутствует в среде.

В-третьих, нужно знать, как запустить обновление каждой системы в целевой среде.

Если автоматизации обновления в системе недостаточно, то запрос на установку попадает к конкретному специалисту, который обновляет систему.

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

Удобно, когда скрипты обновления запускаются единообразно.

Процесс обновления тестовой среды

Благодаря доработкам обновление тестовой среды выглядит так:

1. Лидер продуктовой команды или владелец тестовой среды создаёт в Jira запрос на обновление, в котором указывает название среды и целевой релиз.
2. Jira создаёт отдельные запросы для каждой системы и назначает ответственных специалистов.
3. Скрипт обрабатывает запросы настроенных систем, запускает обновление и закрывает запросы по окончании обновления.
4. Запросы по некоторым системам обрабатываются вручную.

Инициатор может отслеживать прогресс обновления.

Принципы построения CI/CD-pipeline

Давайте теперь спустимся на уровень ниже и посмотрим, как должны быть устроены CI/CD-pipeline для системы, чтобы соответствовать такому подходу. Будем отталкиваться от свойств дистрибутива.

Дистрибутив должен быть:

1. Системным, то есть должен содержать необходимые артефакты для обновления всех компонентов системы. Не должно быть такого, что какой-то из необходимых компонентов — например, sql-скрипты для базы данных — обновлялся отдельно вручную.
2. Кумулятивным, то есть содержать все изменения, а не только дельту от предыдущего дистрибутива/версии/релиза. Без кумулятивности сложно автоматизировать правильную последовательность установки в разные по состоянию среды. Эта проблема возникает обычно на бэковых системах, построенных вокруг баз данных, или на специфических движках. В таких случаях довольно сложно сделать кумулятивные сборки, но к этому нужно стремиться.
3. Версионным. Каждая сборка должна помечаться уникальной версией, которая обычно состоит из порядкового номера сборки и ещё какого-либо признака более общей версионности — мы используем номер релиза. Версия системы выглядит так: [Номер_релиза].[Номер_спринта].[Номер_сборки], например, 112.0.0.123, где 112.0 — это номер релиза, 0 — если спринты не используются, 123 — номер сборки. Привязка к номеру релиза имеет ключевое значение. Именно по ней определяется принадлежность дистрибутива к релизу и формализуется его поиск.
4. Сохраняться в хранилище артефактов, в нашем случае в Nexus. Структура хранения тоже должна быть формализована так, чтобы всегда можно было найти нужные артефакты по номеру версии или последнюю успешную сборку для системы-релиза.
5. Средонезависимым. Дистрибутив не должен содержать никаких средозависымых параметров. Все средозависимые параметры должны содержаться в inventory-файлах скрипта развёртывания, в дополнительных хранилищах секретов.

Сборочный скрипт приложения или CI-pipeline должен быть устроен так, чтобы в результате порождать дистрибутив, соответствующий всем этим свойствам.

Управление конфигами приложения тоже должно быть автоматизировано. Параметры и шаблоны конфигов должны входить в состав скрипта деплоя системы.

Итоги внедрения скрипта обновления тестовой среды

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

В планах сделать процесс полностью автоматическим и сократить время обновления до нескольких часов – осталось только доавтмоатизировать несколько систем и вписать их в общий процесс.

Однако многие компании сталкиваются с проблемами в автоматизации обработки неструктурированных документов в формате PDF или JPG. Это могут быть договоры от контрагентов, выставленные счета от подрядчиков, заявления от клиентов.

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

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

Данные в подобных документах не структурированы. К тому же, у разных клиентов и контрагентов существует много форматов этих данных.

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

В таких случаях не обойтись без применения технологий машинного обучения, что позволит сделать автоматизацию процессов «умной». Иными словами, необходима Intelligent Automation Platform (IA Platform).

Итак, для автоматизации обработки неструктурированных документов необходимы три компонента, каждый из которых требует своего уникального стека технологий и подходов. В статье мы расскажем, как используем их в ИТ-компании ИБА в работе нашей платформы «Канцлер RPA».

Компонент № 1: распознавание

На рынке есть большое количество различных движков Optical Characters Recognition (OCR): и платных, и open source. Мы решили изучить, какие технологии наиболее зрелые, и выбрать те, которые больше всего подходят под наши требования. Важна была возможность использования в коммерческих целях, а также хорошее качество распознавания отсканированных документов.

Мы выбрали для себя Tesseract OCR. Это разработка HP, перешедшая в open source благодаря Google. Также мы обратили внимание на амбициозный проект, который зачастую показывал лучшие результаты — PaddleOCR. Его мы внедрили в платформу как альтернативный движок.

Для повышения качества OCR мы делаем предобработку документов, используя ImageMagick. Большинству документов, с которыми мы встречаемся на практике, достаточно базовой предобработки, которая включает в себя изменение DPI картинки, обесцвечивание, выравнивание возможного наклона документа, удаление прозрачности.

Установка ImageMagick выполняется следующей командой:

● Для CentOS, Fedora:

yum -y install ImageMagick

● Для Debian, Ubuntu:

apt-get -y install imagemagick

Например, у нас есть картинка с именем «input.png». Для ее предобработки мы предлагаем команду со следующими параметрами ImageMagick:

Здесь видно, что обычно мы используем конвертацию DPI в 350 точек на дюйм. В официальной документации Tesseract есть упоминание о том, что движок лучше работает на картинках, у которых «хотя бы 300 DPI», но ничего не сказано про подходы к определению наилучшего значения. Однако они ссылаются на интересные эксперименты, которые показывают, что выбор правильного значения DPI лучше всего рассчитывать по высоте заглавных букв в тексте картинки, которую мы обрабатываем.

Мы повторили эти эксперименты. Из них следует неожиданный вывод об оптимальном размере заглавных букв в пикселях. Казалось бы, чем больше размер букв, тем количество OCR-ошибок должно быть меньше. На самом деле все оказалось не так, и минимальное количество ошибок Tesseract версии 4.0.0 допускает при вертикальном размере заглавных букв в пределах 20-35 пикселей.

Разумеется, все зависит от используемого в документе шрифта. Однако, в большинстве официальных документов используются одни и те же шрифты примерно одного и того же размера. Поэтому мы предлагаем именно 350 DPI как базовую настройку, что обычно изменяет размер заглавных букв как раз на 20-35 пикселей.

Вот пример предобработанного документа, где был исправлен наклон, увеличен контраст и использованы только черные и белые цвета:

Компонент № 2: тегирование

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

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

Чаще всего к нам приходит документ в формате PDF, который мы конвертируем в картинку, используя ImageMagick и Ghost Script. Предположим, мы получили вот такую картинку:

Далее документ отправляется на OCR. Результатом работы OCR будет следующая HTML-структура:

Мы видим иерархию следующего вида: каждый документ делится на страницы («ocr_page»), у каждой страницы могут быть колонки («ocr_carea»), у колонки есть параграф («ocr_par») и так далее до самой мелкой структуры — слова («ocrx_word»). В атрибутах каждого блока есть информация о его расположении относительно оригинального документа. Например, «bbox 2215 236 2443 288» означает, что верхний левый край слова начинается в координатах X=2215, Y=236, а правый нижний край — X=2443, Y=288.

Таким образом, на UI к нам приходит картинка оригинального документа и OCR-результат с извлеченным из него текстом с координатами.

Далее мы отображаем картинку документа в обычном теге, без каких-либо дополнительных слоев. Начинаем отслеживать JS-события перемещения мыши по картинке и событие выделения. Когда пользователь выделяет какую-либо область на картинке, в обработчике события мы получаем координаты выделенной области. Теперь перед нами стоит задача определить, какие области из OCR-результата затрагивает выделенная область. Это простая математическая задача о пересечении одной области с другой. Но эта операция должна выполняться максимально быстро, т. к. пока пользователь проводит мышкой, выделяя все большую область, мы каждый раз должны пересчитывать пересечение областей. Для оптимизации процесса мы решили конвертировать HTML формат в JSON с сохранением структуры вложенности. Таким образом HTML из примера выше примет следующий JSON-вид:

Теперь, получая координаты пользовательского выделения, мы начинаем идти по структуре OCR-JSON вглубь дерева вместо того, чтобы перебирать координаты каждого извлеченного слова. Например, на уровне параграфа мы сразу можем понять, стоит ли опускаться на уровень ниже к линиям или перейти к следующему параграфу для поиска вхождения.

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

В качестве выходных данных мы также используем JSON, который содержит в себе информацию об извлеченных сущностях и их относительные координаты. Такие данные несут в себе основную ценность и в дальнейшем используются для обучения Machine Learning (ML) модели:

Компонент № 3: извлечение

Для автоматического извлечения текста мы выбрали ML-библиотеку SpaCy, которая поддерживает 60+ языков, быстро тренируется, имеет множество преднатренированных моделей с использованием нейронных сетей.

Наша платформа предполагает обработку документов из различных сфер: это могут быть банковские выписки, страховые заявления, ритейл-счета, анкеты для HR-отделов и т. д. Поэтому под каждый вид документов конкретного клиента мы обучаем отдельную модель, что позволяет добиться лучших результатов. Благодаря разработанному компоненту тегирования документов процесс генерации обучающего набора не требует специализированных знаний в области ML. Обычно этот процесс выполняют Subject-Matter Experts (SME) — сотрудники клиента, которые до автоматизации занимались извлечением таких данных вручную, и именно они лучше всего знают, какой текст должен быть выделен в конкретном документе.

Один из главных вопросов при автоматизации обработки документов — какое количество исторических документов требуется для обучения ML-модели. Мы определили, что для быстрого старта первой версии модели, которая сразу же начнет приносить пользу, достаточно от 50 до 100 документов. Чтобы определить оптимальное количество документов, мы провели эксперименты по обучению моделей, в которых изменяли только размера тренировочного набора. Для каждой модели мы высчитывали такие показатели, как Accuracy, Precision, Recall и F1 Score. Оказалось, что оптимальным количеством является примерно 500 документов. При дальнейшем увеличении количества документов не происходит существенного улучшения точности.

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

Таким образом, умная автоматизация сочетает в себе возможности роботизации процессов и машинного обучения. Тщательное исследование доступных open source решений и грамотная работа над обучением ML-моделей позволила нам создать RPA-платформу, которая отлично справляется с обработкой неструктурированных документов. Пользователю же при этом кажется, что он просто выделяет мышкой слова.

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

Особенно важно это для служб поддержки в такси. Поддержка сталкивается с несколькими типами клиентов: водителями, пассажирами и таксопарками. Популярность агрегаторов такси при этом только растёт. В период активного роста через Ситимобил, например, совершалось 13 млн поездок ежемесячно.

В среднем 8% пользователей обращались в службу поддержки: это 1 млн обращений в месяц. Большинство из обращений требуют срочного ответа, ведь пользователь не будет ждать ответа несколько дней, когда что-то идёт не так прямо сейчас, в поездке.

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

Поиск решения лежит в понимании трех операционных метрик любой службы поддержки:

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

Таким образом, инициативы так или иначе влияют на формулу:

(Число обращений) х (Стоимость обработки одного обращения) = (Затраты на службу поддержки)

Стоимость обработки одного обращения рассчитывается так:

(Стоимость обработки одного обращения) = (Зарплатная ставка в час) / ((60 минут) / (Время обработки одного обращения)) / (% времени, когда сотрудник работает)

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

В нашем кейсе, результат принесли проекты по сокращению числа обращений и сокращению времени обработки. При этом, важно было сохранить живое общение с пользователем и сохранить гибкость в управлении поддержкой. Исследовав рынок и учтя факторы, мы разработали собственного рабочего места сотрудника.

Проект, запущенный в начале 2020 года, завершился весной 2022. Было два магистральных направления работы:

• новое рабочее место для быстрой обработки обращений с командой из одного продукта, пяти разработчиков и одного тестировщика,
• автоматизации для сокращения входящих обращений с командой из одного продукта и трех  ML-разработчиков (специалисты по машинному обучению).

В течение работы над проектом, продуктовая команда работала совместно с командой клиентского сервиса, чтобы учесть специфику работы линейных сотрудников.

Рабочее место сотрудника поддержки

Основная задача — максимально упростить работу сотрудников с обращениями в каналах: чат и звонок. Метрика, которую оптимизировали — Время обработки одного обращения (average handling time или АНТ).

Она считается так: замеряется время, которое сотрудник тратит на разговор или переписку с пользователем, а также на административные вопросы, связанные с одним обращением. Можно измерить через статусы в системе или сделав хронометраж работы сотрудника с секундомером.

Проект начался с трехстороннего исследования проблем старого рабочего места и потребностей сотрудников. Продуктовая команда проводила глубинные интервью как с руководителями, так и с линейными сотрудниками.

Примеры вопросов:

• На какие типы обращений тратишь больше всего времени?
• Что бы хотел изменить в текущем рабочем месте?

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

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

Наконец, команда изучала практики конкурентов и поставщиков готовых решений.

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

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

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

• отменить заказ с возвратом денег за отмену,
• пересчитать платное ожидание,
• проставить статус или тему обращения,
• вернуть деньги, списанные за поездку.

Действия сотрудников были проранжированы по частоте. Эта частота определила порядок добавления новых фичей и действий в рабочее место. Второй фактор — затраты времени сотрудника на совершение действия. Например, если “возврат денег за поездку” — самое частое обращение пользователей и новый интерфейс позволит делать это быстрее — внедряем этот функционал в первую очередь.

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

С технической стороны, команда разработки делилась на frontend, backend, qa и дизайнера.

Frontend реализовывался на ReactJS и отвечал за пользовательские интерфейсы (UI). В нашем случае, это те самые действия сотрудника с обращением.

Backend реализовывали на фреймворке Symfony языка PHP. Бэк занимался API и закрытой админкой для настройки рабочего места сотрудника. Каждая фича выкатывалась под ручкой и можно было гибко настраивать функционал под нужды сотрудников поддержки. В том числе, возможность отключить функционал для некоторых групп сотрудников. Это важно, например, для стажеров, которым рано давать доступ к операциям с деньгами.

На момент полного внедрения  AHT сократился с 230 секунд до 195 секунд для звонков и с 500 до 385 секунд по чатам. Эффект получили за счет ухода от переключения между окнами.

Кроме этого, сработала фича:

• подсказки при выборе тематики обращений. ML-команда научила систему анализировать десятки параметров при поступлении звонка и по итогу отдавать топ 5-10 вероятных тематик обращения. Такие предсказанные предложения тематик сократили время обработки звонка на 4 секунды.

Суммарно же сокращение АНТ принесло компании экономию бюджета службы поддержки на 20%.

Интерактивное голосовое меню (Interactive Voice Response, IVR) и чат-боты

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

В звонках использовались два подхода:

• IVR, позволяющий получить информацию или совершить самостоятельное действие. Пример: для отмены заказа, нажмите 5 или скажите “отмена”,
• Автоматическая маршрутизация, когда система сама понимает, с кем нужно соединить пользователя.

Команда не разрабатывала новых фичей, а сфокусировалась на анализе схем маршрутизации и причина обращений на этапах пользовательского пути. Вопросы при анализе:

• Что мы знаем о пользователе? Например, статус заказа, наличие открытого обращения в поддержку
• Почему он или она сейчас обращается в поддержку?
• С какой вероятностью можем это угадать?

Изменение логики или фразы проверялось на группе пользователей перед раскаткой на базу.

За счет новой логики работы IVR и маршрутизации сократилась потребность в соединении с оператором.

Примеры удачных логик IVR:

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

Примеры маршрутизации:

• в случаях, когда машина подана, пассажир напрямую соединяется с водителем через маскированный канал, так как в сценарии  частая проблема — найти друг друга.

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

С технической точки зрения, логики были реализованы через API поставщика услуг связи. Каждый новый сценарий привязывался через него и менял настройки телефонии.

В итоге, удалось автоматически закрывать 35% обращений: из них 17% заслуга чат-ботов, остальное IVR и маршрутизация.

Итоги проекта

В результате этого проекта компания получила ощутимую экономию затрат. Оценить эффект можно по формуле (стоимость обращения индикативная):

Без автоматизации:

Обращения в месяц: 1 млн

Стоимость обработки одного обращения: 10 руб.

Итого затрат в месяц: 10 млн руб.

С автоматизацией:

Обращения в месяц: 1 млн — 35% = 650 тыс. (те, которые попадут к сотруднику)

Стоимость обработки одного обращения: 10 руб. — 20% = 8 рублей (те же сотрудники, но работают на 20% быстрее)

Итого затрат в месяц: 5,2 млн руб.

Естественно, эти цифры не учитываю затрат на разработку, но решение хорошо окупается на горизонте 2-3х лет. Кроме этого, совместная работа над проектом позволила повысить мотивацию и вовлеченность сотрудников службы поддержки. Провели оценку удовлетворенности сотрудников службы поддержки до начала проекта и после завершения. Удовлетворенность выросла на 17%, при этом сотрудники положительно отмечали:

• обучение новому, работая с технической командой,
• чувство причастности из-за участия в большом проекте,
• возможность повлиять на ежедневную работу.

Этот дополнительный эффект тоже стоит учитывать при оценке результатов проекта.

На первый взгляд, стать самым быстрым программистом — отличная цель. Кто успевает сделать больше фич, тот и приносит компании больше денег, да? А кто приносит больше денег, тому и самую большую зарплату, правильно?

Уверен, кто-то сейчас ухмыльнулся, вспомнив своего коллегу, который всех в команде бесил своими быстрофиксами и костылями. Похоже, компаниям важны не столько быстрые программисты, сколько быстрые команды.

Ну хорошо, а как замерить скорость программиста или команды?

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

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

Кейс HP LaserJet

В 2008 году компания Hewlett Packard обнаружила себя в трудной ситуации. Исследование показало, что на разработку нового функционала HP LaserJet у компании оставалось лишь 5% всего времени — все остальное съедали сложности, возникающие при разработке кода под множество устройств.

Это заставило компанию запустить большую перестройку процессов. Новые процессы базировались на идеях экстремального программирования.

Ключевые нововведения:

• Практически полностью автоматизированное тестирование;
• четыре уровня проверки кандидата к релизу — от самых быстрых тестов с частотой до 12 прогонов в день до самых медленных с частотой до 1 раза в сутки;
• автоматизация инфраструктуры и развертываний. Любые изменения вплоть до конфигураций проходили через систему контроля версий и тесты, откуда автоматически развертывались на стенды;
• короткие циклы планирования вместо разработки больших проектов на много месяцев вперед;
• и самое радикальное — разработка на одной ветке, или, как сейчас говорят, trunk based development. Каждый день в главную ветку вливались по 10-14 коммитов, что позволило предотвратить все варианты интеграционных конфликтов.

В результате удалось добиться сокращения затрат на большинство активностей в разы. Это позволило высвободить время для инноваций: процент времени, затрачиваемого на новый функционал, увеличился с 5% до 40%.

Самое интересное тут то, что времени на тестирование не стало меньше, оно даже, наоборот, удвоилось: несмотря на то, что ручное тестирование сократилось в три раза, теперь 23% всего времени уходило на автоматические тесты. То есть, увеличив время на автоматическое тестирование и автоматизацию инфраструктуры, компания смогла тратить меньше на остальные активности. Таким образом скорость разработки выросла на невероятные 700%.

Сильные и слабые команды

Это не столько частный случай, сколько общая практика. В 2016 году организация DORA в ежегодном исследовании State of Devops опубликовала свои замеры.

Оказалось, что сильные команды тратили на переделывание и незапланированную работу на 22% меньше, а на новую работу на 29% времени больше, чем слабые. Через год разрыв увеличился: сильные команды стали тратить на переделывание и незапланированную работу на 26% меньше и на 44% больше на новую работу. Таким образом, сильные команды в среднем тратят почти в полтора раза больше времени на полезную работу.

Дизайн исследования специально был построен таким образом, чтобы сильные команды объединял все тот же высокий уровень автоматизации тестирования и развертывания. В слабых командах же, напротив, значительно больше было ручной работы.

Зачем нужна автоматизация

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

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

Ну хорошо, а кто должен писать все эти тесты?

Здесь все то же исследование State Of Devops демонстрирует еще более удивительную связь: тесты, написанные тестировщиками или даже отдельными командами, как оказалось, ничем не помогают. Только тесты, написанные самими разработчиками, позволяют добиться повышения эффективности команды.

Почему так?

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

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

Ладно, автоматизация важна. Как и что автоматизировать?

Это крайне обширная тема, которая максимально подробно освещена в книге «Непрерывное развертывание программного обеспечения» (Continuous Delivery) авторства Дейва Фарли и Джеза Хамбла.

Давайте попробуем вкратце описать процесс разработки в условиях полной автоматизации тестирования, развертывания и инфраструктуры.

Центральным элементом такого процесса является паттерн «Конвейер развертывания» (Deployment pipeline). Согласно этому шаблону, каждый коммит, попавший в главную ветку в системе контроля версий, запускает старт этого конвейера.

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

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

После успешного прохождения тестов вторым шагом в репозиторий публикуется собранный кандидат к релизу, например docker-контейнер или иной артефакт.

За этим следует шаг с развертыванием приложения на тестовый стенд и конфигурацией стенда. Здесь происходят все накаты миграций баз данных и все изменения настроек приложений.

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

Ни в коем случае нельзя настраивать вашу инфраструктуру вручную. Это приводит к антипаттерну «Сервер-снежинка» (Snowflake Server), когда ваш сервер уникален и неповторим, подобно снежинке. Нет ни малейшей гарантии, что то, что работает на вашей снежинке, будет работать хоть где-то еще.

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

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

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

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

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

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

Главный результат такой автоматизации: код непрерывно находится в готовом к развертыванию в продакшн состоянии, каждый новый коммит — новый релиз.

У кого-то вышеописанные процессы могут вызвать лишь ухмылку. Мол, в идеальном мире розовых единорогов такое бы, может быть, и было возможно. Отнюдь. Именно такого преобразования и удалось добиться компании HP Laser Jet и многим другим известным крупным компаниям. Но соглашусь, это высший пилотаж, требующий высокой грамотности разработчиков в области тестирования и автоматизации инфраструктуры. Впрочем, в этом и цель моего повествования: указать на ориентиры в профессиональном развитии специалиста.

Ну хорошо, автоматизация рулит, договорились. Есть ли какие-то другие способы ускорить команду?

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

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

Как с этим бороться? Есть три способа:

1. Приоритизировать простоту (правило: пишем самое простое, что может работать).
2. Рефакторинг. Всегда оставляйте код в лучшем состоянии, чем вы его застали. Наряду с первой практикой это позволит вам не только не вносить новую сложность в систему, но и постоянно ее сокращать.
3. Постепенно заменяйте ручные операции (тестирование и развертывание) автоматизированными.

Но самое дорогое в разработке программного обеспечения — работать не туда

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

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

—Что значит «изменить чье-то поведение»?—Если через 9месяцев, когда фича будет готова, все будут делать тоже, что исейчас, как будто ничего непроизошло, это будет провал?—Конечно, провал!—Тоесть кто-то должен что-то делать иначе?—Мыхотим, чтобы пользователи публиковали свои достижения в«Фейсбуке».—Уже лучше. Зачем?—Всмысле— зачем? Чтобы ихдрузья увидели эти посты.—Тоесть насамом деле мыхотим изменить поведение людей, которые неиграют вигру. Нухорошо, апочему это важно?—Если другие люди прочитают эти посты, то, возможно, они придут попробовать эту игру.—Хорошо, это еще одно изменение поведения, но все еще недает общей картины. Почему это важно?

Владелец был потрясен:

—Это глупый вопрос. Чем больше игроков, тем больше денег.—Хорошо, тоесть мыхотим больше игроков?—Конечно!—Насколько больше?—Чем больше, тем лучше.—Если спустя 9месяцев эта фича приведет 5 новых игроков, это будет успех?—Нет, конечно, мырассчитываем намиллион игроков.

Бинго! Эта цифра все время была в голове у владельца, но до разработки дошла лишь после этого разговора. В итоге первое, что требовалось сделать, — проверить, насколько идея жизнеспособна. За пару часов работы была реализована возможность опубликовать сообщение о победе в игровом турнире, однако оказалось, что за 3 дня никто так и не нажал кнопку «поделиться» — никто не хотел спамить своим друзьям сообщениями о какой-то игре в «Фейсбуке». Таким образом, это направление оказалось заблокировано.

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

Эта история позволяет сформулировать очень интересные выводы::

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

Согласно исследованию компании Microsoft, 2/3 всего разработанного функционала в лучшем случае не принесло никакой пользы. Это означает, что можно иметь крутейшую архитектуру, в которой нет ни строчки лишнего кода и избыточной сложности, можно иметь невероятные процессы, в которых каждый коммит после прогона всех видов автотестов тут же деплоится в прод — но если вы работаете не туда, то 2/3 вашей работы в лучшем случае не принесут никакой пользы. И, как правило, такие фичи лежат в кодовой базе и мешаются под ногами, съедают время в прогонах тестов, техподдержке приходится поддерживать эти фичи до самого конца продукта — а ведь ими никто и не пользуется.

Получается, что компании выгоднее было бы, если бы вы эти 2/3 времени провели на пляже, ну или на горнолыжном курорте, или просто с родными…

Вывод

Подведем итоги:

• Автоматизация тестирования и инфраструктуры приводит к росту продуктивности в среднем в полтора раза. В отдельных случаях удавалось зафиксировать рост в 8 раз.
• Центральным элементом такой автоматизации является шаблон «Конвейер развертывания». Главный результат: код непрерывно находится в готовом к развертыванию в продакшн состоянии, каждый новый коммит — новый релиз.
• Другой проблемой становится трясина легаси-кода. Главные сдерживающие факторы — запутанная структура и дорогие баги. Главные лекарства — простой дизайн, рефакторинг и автотесты.
• Самое дорогое препятствие к решению проблем бизнеса — неверно выбранный вектор работы. Очень важно, чтобы все участники процесса хорошо понимали цель, правильно выбирали метрики и работали в коротких циклах, позволяющих ошибаться быстро и дешево.

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

Как система росла

Сначала система называлась Jarvis в честь персонажа комиксов Marvel. Её целью было высвободить ресурсы сотрудников ИТ для более сложных задач. Jarvis постоянно развивался. Со временем он интегрировался с другими внешними системами: от Gitlab до мониторинга уязвимостей, стал связываться с базами данных, исполняя SQL-код. Среди рабочих инструментов автоматизации — умение работать с файлами Excel, запускать PowerShell и Bash-скрипты на удалённых серверах. Теперь система может загружать сайты, имитировать действия человека: вводить текст в поля, нажимать кнопки, переходить по страницам. Это используется для отправки запросов в MailStream. В июле текущего года Jarvis (теперь он называется Robot Vision) научился работать с новейшей системой управления услугами банка, ITSM Ivanti.

Система автоматизации занимает одно из ключевых мест в ИТ-ландшафте банка

Автоматизация всех рутинных задач банка

В Vision (краткое имя от Robot Vision) приходят заявки на автоматизацию какого-либо действия. Например, разблокировку учётной записи или перевод заявок по статусам на кредитном конвейере. Робот принимает заявку и запускает специализированный обработчик.

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

От открытия заявки до её выполнения проходит от часа до одного рабочего дня. В сутки система обрабатывает около 600 обращений.

Ключ к повышению производительности

В 2019 году мы работали с порталом самообслуживания для сотрудников банка HP Service Manager (HPSM). В нём регистрировались обращения, инциденты, все внутренние заявки. Например, запросы на обновление систем или установку ПО.

В HPSM есть несколько типов запросов. Мы обрабатывали только один — это sub-quote (SQ). В систему приходил номер sub-quote. Мы прямо в ядре запрашивали нужную информацию по ней. Забирали имя основного запроса и сравнивали его с обработчиками в базе данных для получения JS тела скрипта, отвечающего за автоматизацию.

Количество заявок было низким. При этом система не успевала обработать весь входящий поток. «Дорогие» специалисты тратили много времени на рутину.

Подход пришлось изменить, он стал более гибким. Теперь мы не проводим операций по определению имени задачи в ядре, а сразу делим задачи на группы автоматизации, у которых есть ключи определения обработчика (Key-Value-Pair) и свой «предобработчик». Предобработчик на основе полученных данных генерирует набор ключей-значений для последующего поиска обработчика. Происходит это так:

1. Мы определяем тип запроса, например, SQ.
2. Находим группу обработчиков, которые работают с этим типом. Нужный обработчик находим по ключу action, он указывает, какое действие необходимо совершить с запросом. На обработчике также указан ключ, значение которого равно действию, например, разблокировке учётной записи.
3. Обработчик выполняет нужное действие.

Как и раньше мы ищем обработчик по наименованию задачи, но вдобавок имеем гибкую систему, которая способна интегрироваться с любой другой. Можем не привязываться к имени задачи, а искать по любому другому параметру или набору параметров хоть из 100 различных источников. Раньше мы обслуживали только SQ-заявки, а сейчас можем обрабатывать и RFC (запросы на изменение), и инциденты.

Сократили код в 26 раз

Скрипт — это кодовая часть обработчика, то есть самой автоматизации. Чем проще писать скрипты, тем быстрее обработчик будет готов, и автоматизация будет раньше поставлена на прод.

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

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

Я перевёл скрипты на GitLab и сократил количество кода в 26 раз. Для разработчика автоматизации ничего не поменялось, а вот под капотом мы провели большую оптимизацию процесса.

Сейчас чтобы автоматизировать процесс, не нужно копипастить. Весь основной код вынесен в встраиваемые пакеты на базе JS, например: HPSMPackage, JiraPackage и многие другие.

Функционал по подключениям, специфичный API и другие вспомогательные методы вынесены во встраиваемые пакеты. Это тоже JS код, просто хранящийся в пакетах, которые импортируются в скрипты с бизнес-логикой методом require.

Например, обработчик «Обновление тестовых сред». В скрипте с бизнес-логикой сейчас содержит всего 75 строчек кода и два подключения: package/gitlab, package/hpsm/sq. package/gitlab содержит 260 строчек кода. package/hpsm/sq — 365 строчек. И всего таких пакетов у нас 29. Некоторые из них могут содержать значительно больше кода.

Скрипты автоматизации настраивают взаимодействие между разными системами. В них сделан акцент на ключевых действиях, компактности кода, простоте использования и доработок

Подняли скорость деплоя от получаса до минуты

Раньше мы публиковали приложения, разработанные на .Net, на Windows-хостах под управлением IIS. Нам приходилось вручную заходить на сервер, подключаться по административному логину и паролю, загружать на хост пакет с приложением, разворачивать, останавливать IIS, разворачивать его заново. На это уходило в среднем пятнадцать минут — или полчаса, если возникали какие-то затруднения.

Теперь мы используем GitLab как систему для сборки кода, отправки его в репозиторий, в редких случаях для публикации этих пакетов на хостах. AWX используется как система для деплоя. Это сократило время публикации в разы.

По шагам это выглядит следующим образом:

1. Мы публикуем код в систему контроля версий.
2. Нажимаем кнопку «отправить на тест» или «отправить на препрод».
3. Запрос уходит в AWX, он получает собранный пакет из GitLab либо из другой системы хранения кода.
4. Запускается скрипт публикации на конечное устройство, приложение развёртывается. Выставляются необходимые настройки, и меньше чем через минуту мы видим результат.

Автоматизация доставки изменений сократила время публикации скриптов от получаса до минуты

Расширили функциональные возможности системы

Система получила обновления в виде модулей по работе с Powershell, Excel, CSV и прочими атрибутами корпоративных дел. Теперь чтобы подключиться к серверу и выполнить команду Powershell или Bash, достаточно ключей и адреса.

Реализовали на связке JS и C# с помощью движка Jint

Мы выбрали JS из-за его популярности и простоты — легче находить в команду новых людей и вводить их в курс дела.

В целом, совмещение C# с JS звучит странно, это разные языки. Но они похожи в одном — оба являются интерпретируемыми, но по-своему. Разные синтаксис, спецификации, среды исполнения.

Мы используем JS как язык разработки скриптов автоматизации. Можно было разрабатывать всё на C#, поскольку на нём написан backend. Но это долго и сложно, это нужно компилировать. Можно было подключить Python или F#, последний тоже живёт в контексте .Net. Мы этого не сделали потому, что текущих реализаций достаточно. В банке упор делается на другие вещи — экономичность и производительность.

Поначалу JS был встроен в проект неудобно. Часть общего JS кода писалась в .cs файлах, встраивалась в контекст движка Jint и тем самым дополняла функционал скриптов автоматизации. Со временем мы переписали эти расширения на C#.

Jint даёт набор инструментов, позволяющий настроить среду исполнения интерпретируемого кода, с его помощью мы связали C# и JS. Его задача — интерпретировать JS код и выполнить его в среде .Net. Движок Jint создаёт контекст выполнения, в рамках которого мы можем исполнять JS код, подгружать в него необходимые модули и встраиваемые пакеты. Благодаря Jint мы можем работать с результатами выполнения JS скрипта в контексте C# и наоборот.

Jint — это самая известная и простая библиотека. Она легко встраивается, реализует весь нужный нам функционал и развивается до сих пор. Чтобы начать пользоваться Jint, нужно только создать экземпляр движка и выполнить JS скрипт:

Для объявления функции выполним следующий код. Таким же образом можно объявить переменную:

Если необходимо встроить типы целой сборки в контекст движка:

Из движка также можно вытащить все переменные контекста:

Конечно, можно было использовать NodeJs, и запускать JS скрипты на нём, но тогда бы мы потеряли функционал расширения скриптов из .Net, и не смогли бы также легко забирать объекты из результата выполнения.

У Jint есть минусы. Хоть библиотека и развивается, она поддерживает не все функции спецификации ECMAScript. Сейчас есть намного более мощные инструменты, библиотеки, но они сложнее в реализации. Нашей основной задачей было сделать быстро и просто.

В реализации Jint тоже были затруднения, например в работе с JObject внутри движка.

Мы не могли просто взять и передать объект JSON (JObject из Newtonsoftjson) в бизнес-логику, у нас постоянно возникали вопросы с доступом к свойствам объектов, в работе с коллекциями и перечислениями. Поскольку дедлайны были близки, мы решили конвертировать объект в JSON строку и распарсить обратно внутри самого движка Jint.

Результаты автоматизации процессов банка

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

Сейчас система реагирует моментально и обрабатывает заявки одного типа в среднем за одинаковый промежуток времени. В месяц таким образом обрабатывается около 15000 обращений. Теперь операторы занимаются только сложными заявками.

Разные команды банка обращаются к нам для автоматизации процессов, от простых до сложных. Например, система может выполнить заявки по постановке сервера на мониторинг уязвимостей, выполнить копирование базы данных, настроить принтер, переместить имущество в системе между офисами, выдать сотруднику права после выхода из отпуска по уходу за ребёнком.

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

Что это такое

Programmatic-маркетинг (англ. Programme и Automatic) —  автоматизированная закупка таргетированной рекламы в Интернете.

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

Programmatic форматы:

1. Нативная реклама
2. Баннеры
3. Видео
4. Аудио

Основные каналы:

1. Социальные сети
2. Сайты
3. Мобильные приложения

Плюсы Programmatic:

1. Кроссплатформенность. Реклама демонстрируется и в десктоп, и в мобильной версиях.
2. Точный таргетинг. Информация из Cookie, User Agent и других открытых источников определяет модель пользователя с точностью 75-80%.
3. Ставки. Гибкая стартовая цена показа поможет скорректировать бюджет в самом начале.
4. Оптимизация объявления. Своевременная корректировка кампании для достижения наилучшего результата на основе статистики.
5. Широкий охват. Возможность охватить несколько площадок разного типа.
6. Экономия времени и возможность запустить рекламу самому.

Чтобы запустить успешную Programmatic-рекламу потребуется всего несколько шагов:

• Анализ целевой аудитории, разделение её на сегменты и выбор основной цели рекламной кампании.
• Разработка креатива.
• Выбор платформы для покупки рекламной площадки. Нужно обращать внимание на наличие релевантных сайтов с хорошей репутацией и высоким охватом.
• Настройка таргетинга с ориентиром на целевую аудиторию.
• Отслеживание ключевых показателей эффективности. 

С плюсами и шагах подготовки разобрались. Теперь переходим к выбору формата закупки рекламы.

Они делятся на три типа:

Programmatic Direct — прямая сделка между паблишером и рекламодателем.

Private Exchange Buying — это закрытое коммьюнити, в котором состоят избранные рекламодатели и паблишеры. Тут сделки заключаются по собственным правилам.

Real Time Bidding (RTB) —  популярный формат, с помощью которого проводятся 90% закупок. Представляет собой интернет-аукцион, где рекламодатели выкупают внимание пользователя на ресурсе паблишера.

Об этом и расскажем подробнее.

Составляющие RTB

В этом аукционе участвуют четыре стороны:

1. SSP
2. DSP
3. DMP
4. Пользователь, как конечный потребитель

Supply Side Platform (SSP; платформа на стороне предложения) – часть RTB, работает на стороне паблишера. Её главная задача — продать места для рекламы на сайте паблишера за максимальную цену.

Оптимизирует доход владельца сайта, подключаясь к нескольким DSP.

Demand Side Platform (DSP; платформа на стороне спроса) – эта платформа работает на стороне рекламодателя и способна автоматически закупать пространство под рекламу на ресурсах, чтобы привлечь внимание пользователя.

Благодаря DSP процесс закупки рекламы стал проще, а отслеживать эффективность рекламы стало легче.

Data Management Platform (DMP; платформа управления данными) – собирает, структурирует и продаёт информацию пользователях из открытых источников, Cookie и User Agent. Это помогает в поиске новой клиентуры, схожей аудитории, повышении таргетинга.

К DMP обращается DSP для получения данных о пользователях, чтобы принять решение об участии в аукционе.

О работе RTB

Когда пользователь посещает сайт, специальный код, вставленный в сайт, отправляет информацию о посетителе в рекламную биржу, биржа информирует SSP, которая выставляет лот в виде внимания юзера DSP-платформе.

За то время, пока у пользователя загружается страница, проходит миллисекундный аукцион, по итогам которого выигрывает самая большая ставка. Именно эту рекламу увидит юзер при посещении ресурса.

В чём профит?

Programmatic-реклама и протокол RTB хороши тем, что здесь каждая из сторон получает то, что ей нужно.

Юзер серфит в интернете и видит минимум низкокачественной рекламы, ведь ему показывают объявления релевантные его запросам, которые интересам из Cookies, User Agent и других открытых источников.  модели поведения.

Рекламодатель получает показывает свою рекламу максимально релевантной аудитории, при этом не тратя бюджет впустую. Глубокий анализ эффективности рекламы позволяет скорректировать будущие кампании.

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

Выбор платформы

По данным StatOnline.ru, сегодня в зоне .RU существуют десятки монетизаторов.

Согласно статистике на первом месте стоит Google AdSense, который покинул российский рынок в связи с политическими событиями.

Второе место занимает Рекламная Сеть Яндекса, ставшая после ухода Google спасительной соломинкой паблишеров.

StatOnline демонстрирует, что тысячи сайтов пытаются начать работать с РСЯ и их дочерней фирмой AdFox.

На что обратить внимание при выборе рекламной сети

1. Гибкость и настраиваемость выплат. Обратите внимание, как часто приходят выплаты с разных сетей и сравните результат. Например, Google и Яндекс пользуются системой NET-20. То есть, это означает, что паблишер получит первую выплату после одного месяца и двадцати дней, при достижении установленного порога выплат. Есть сети, которые предоставляют более гибкие выплаты и пойдут на встречу в выборе валюты.

2. Коммуникация. Для продуктивной монетизации важно быстро решать возникающие вопросы, связанные с рекламой. Чтобы этого добиться, выбирайте сеть с качественным и эффективным саппортом. Например, у нашего партнера RBK Games, появилась проблема с рекламой в виде очень громкого звука. Это отрицательно сказывалось на монетизации. Но благодаря хорошо выстроенной коммуникации, наша команда быстро решила вопрос, причем в нескольких регионах сразу. Последующий взрыв трафика и скачок дохода паблишер связывает с качественным выбором рекламодателей и контента с нашей стороны.

3. Качество контента. Вряд ли посетители сайта будут в восторге от низкосортных объявлений в стиле “Секретный способ бросить пить из СССР…”. Навязчивая и постоянно всплывающая реклама вовсе может заставить юзера уйти с ресурса. Чтобы убрать креативы, которые негативно влияют на поведение пользователей, нужно лично отобрать типы, темы и форматы.

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

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

Рекламные сети, работающие в российском сегменте:

• ADlook.me
• Google AdSense
• Yandex.Direct
• DoubleClick Ad Exchange
• AdFox
• Begun
• Admitad
• AdRiver
• Criteo
• MGID
• Google Publisher Tag
• DoubleClick For Publishers

Итоги

Сегодня мы рассказали о Programmatic-рекламе и её составляющих. Углубились в RTB и рассказали про его элементы и принципы работы. Тем, кто зарабатывает на монетизации сайтов, дали несколько советов о выборе рекламной сети.

Изучали ли вы вопросы монетизации и работы с трафиком? Мы продолжим и дальше знакомить вас с интересным миром Programmatic-рекламы и монетизации сайтов.

До связи!

Но сначала немного ликбеза

CI/CD — это целая культура, которая включает в себя набор принципов и реализует последовательность этапов доставки программного обеспечения с момента его написания разработчиком до развёртывания в продуктивном контуре. Собственно, в основе данной аббревиатуры отдельные шаги, которые принято рассматривать в комплексе:

• Continuous integration — непрерывная интеграция;
• Continuous delivery — непрерывная доставка;
• Continuous deployment — непрерывное развёртывание.

Continuous integration (CI) – это упаковка приложения разработчиком и тестирование. На шаге планирования у бизнеса или владельца продукта появляется идея, как улучшить клиентский сервис и какие фичи для этого нужны. На этом же этапе аналитик собирает бизнес-требования и передаёт их разработчику.

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

Continuous delivery – это доставка приложения, то есть обеспечение его работы в промышленной эксплуатации. Здесь важно как минимум одно ручное действие – подтверждение ответственного за вывод в продакшн. Как правило, за это отвечает тимлид команды разработчиков. Непосредственно развёртывание приложения в инфраструктуре клиента должно происходить автоматизированно.

Continuous deployment – это процесс непрерывной доставки кода до продуктива без каких-либо дополнительных согласований и ручных операций. Мониторинг таких выкаток должен также осуществляться постоянно и автоматизированно. Его цель – молниеносно определить проблему с билдом и дать возможность разработчику откатить назад версию приложения и параллельно «пофиксить» ошибки.

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

Распространённые ошибки при реализации CI/CD

Слабо применяется автоматизация

Неработающий конвейер – картина частая. В большинстве случаев это связано с некорректно построенными процессами внутри организации.

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

В результате в 2-3 раза увеличивается срок выпуска в эксплуатацию приложения, а вместе с этим растет количество конфликтов внутри команды, так как сложно понять, на каком этапе процесс стопорится.

Нет формально прописанных зон ответственности

Нередко видим другую ситуацию — в целом процесс CI/СD работает неплохо, но иногда даёт сбой. ИТ-директор одного российского банка как-то жаловался, что при выкатке новой версии релиза часть пакетов и скриптов «не доезжает», а обратная связь о неработающих сервисах при этом приходит не от DevOps-инженеров, а непосредственно от пользователей.

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

Чтобы это исправить, рекомендуется использовать RACI-матрицу. Её, к слову, часто применяют провайдеры. Они «на берегу» определяют, кто и за что будет отвечать в проекте. Например, мы прописываем в документе свою обязанность разворачивать и поддерживать виртуальные машины и инфраструктурные компоненты там, где являемся поставщиками инфраструктуры и кластеров Kubernetes. А сам софт и доступность CI остаются на совести клиента.

Бывает, что клиент поручает нам цикл сборки и доставки целиком – в этом случае мы раскатываем приложение в продуктивную среду, а заказчик фокусируется исключительно на разработке своего продукта.

Отказ следовать IaC

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

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

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

При внедрении роботизированной автоматизации процессов (RPA) в промышленные проекты возникают вопросы. Как этим управлять? Есть ли какие-то стандартизированные подходы для имплементации проекта RPA? Всё это не менее важно, чем написание кода.

В данной статье я приведу в пример распространённую платформу для автоматизации бизнес-решений — UiPath (её облачное — Orchestrator — считается одним из лучших). Посмотрим, какие предложения по облачной автоматизации и управлению RPA-процессами у неё есть.

Основные функции Orchestrator для облачной автоматизации для RPA

• развёртывание — обеспечивает доставку версий пакетов назначенным роботам для выполнения;
• конфигурация — поддерживает и обеспечивает конфигурацию сред и процессов роботов;
• очереди — обеспечивает автоматическое распределение нагрузки между роботами;
• мониторинг — отслеживает общие данные о работе робота и позволяет оценивать продуктивность работающих процессов;
• ведение журнала — сохраняет и индексирует журналы в базе данных SQL и Elasticsearch.

Развёртывание

Система принимает сформированные пользователем процессы в формате собранных nuget-пакетов. А система распределения, выделяет обозначенный ресурс для выполнения кода из пакета (выделяет машину). Это происходит посредством привязки каждого пакета (процесса), под environment исполнения. И, как следствие, из-за специфики выполнения кода RPA-процессов, под определённую машину или сервер.

Конфигурация

Специфика работы процессов RPA подразумевает наличие доступа к desktop для виртуальной машины или сервера, на которых планируется запуск. То есть данные авторизации каждой машины, а так же её унифицированный идентификатор нужно держать в памяти.  Это помогает выполнить часть системы Оркестровки, которая занимается выделением специального номера (machine key) каждой отдельной машине.

Очереди

Учёт транзакций, обрабатываемых RPA-процессами, ведётся в структуре данных — «Очереди». Она позволяет выполнять транзакции очереди, применяя FIFO-метод и учитывая приоритетность задач. Наличие функционала приоретизирования транзакций очень важно при работе на промышленных мощностях. Это позволяет процессу быть более гибким и соответствовать текущим запросам пользователей.

Мониторинг

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

Ведение журнала

Оркестратор, предлагает, как Cloud, так и on-prem решения. То есть вычислительные мощности могут быть и локальными, и из серверов компании UiPath. Для индексации и учёта элементов логов и внутреннего хранилища, которое базируется на SQL при установке локально, используется Elasticsearch.

RPA-аналитика

Вы внедрили у себя RPA. Как понять, что это принесёт пользу? И как понять, увеличилась ли польза со временем? Ответить на эти вопросы поможет RPA-аналитика. Она предоставляет детальную и предиктивную информацию о рентабельности автоматизированных процессов.

Ключевое качество аналитических возможностей RPA — возможность самостоятельно настроить способ определения успеха и результатов. Выбор ключевых показателей, настройка под цели и задачи компании и то в каком виде представлять результаты также остаются за вами.

Для реализации данных функций используется Orchestrator Insights. Это интегрированная в Orchestrator платформа, которая анализирует и представляет данные в кастомизируемом формате. Продуктивность использования лицензий роботов, сбор информации об узких местах автоматизированного процесса — всё это есть в данной облачной системе.

CI / CD применимо для RPA

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

«Конвейер» CI/CD автоматизирует процесс доставки и интеграции любого программного обеспечения для проекта. Для корректной работы, его нужно разработать до написания кода. Это позволит ему работать при написании кода, тестировании и непосредственном внедрении.

Что такое CI/CD?

Непрерывная интеграция (CI)

Непрерывная интеграция — это практика разработки ПО, которую используют, чтобы упростить разработку и тестирование кодов через автоматизацию соответствующих задач. Применяя её в RPA, программисты постоянно интегрируют изменения кода в центральный репозиторий. А тесты проводятся на отдельном сервере.

Непрерывная доставка (СD)

Непрерывная доставка обеспечивает простую упаковку и непрерывное развертывание кода. С её помощью можно  настраивать и упаковывать ПО и организовать его непрерывное развёртывание с меньшими затратами.

Преимущества CI / CD:

• Быстрая доставка: более короткое время оборота обеспечивает быстрое время вывода на рынок.
• Поддержка: обнаружение проблем на этапе сборки бота происходит намного быстрее. Это позволяет быстрее решать проблемы и обеспечивает безошибочное развертывание бота.
• Улучшение: участие конечного пользователя в процессе непрерывной разработки делает использование ПО более удобным. Новые требования по отзывам сторонних разработчиков можно выполнять ежедневно.
• Обновления: пользователи получают обновления вовремя, поскольку их выход с помощью компакт-дисков проще и требует меньше времени. Циклы выпуска, или спринты, короче. А также нацелены и тестируются на отсутствие ошибок перед переходом к новому спринту.
• Мониторинг: ход процесса разработки может быть передан пользователю, что позволяет отслеживать в реальном времени и устранять отложенную обратную связь.
• Релизы: развертывание программного обеспечения – это безболезненное мероприятие с низким уровнем риска, поскольку код можно просматривать и редактировать по запросу.

Применение CI/CD для разработки RPA-процессов

Распространённой считается система имплементации CI/CD с помощью Azure DevOps Pipelines, git-репозитория и docker-контейнеризации. Для примера flow стандартной имплементации CI/CD приведём такую последовательность:

1. Написанный код в UiPath Studio комитится в git-репозиторий. Студия разработки UiPath позволяет нативно настроить интеграцию процесса комита в интерфейс студии.
2. Проведение push-комита тригерит pipeline в системе Azure. В свою очередь она инициирует процесс CI.
3. В docker-контейнере процесс запускается на выделенном для тестирования процесса сервере. Пользуясь встроенными возможностями тестирования кода в UiPath, у нас есть возможность составить unit-тесты для каждой части процесса и составить assessment корректности работы процесса по их выполнению.
4. При успешном завершении тестов контейнер может быть доставлен на продуктивный сервер. Для обновления последней версии кода будет произведен merge с локальным хранилищем.

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

По результатам обсуждений собрали основной бриф:

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

За основу был взят следующий стек технологий и инструментов:

• Система бухгалтерского учёта на платформе 1С Бухгалтерия, Управляемые формы.
• 1С Битрикс24 – как инструмент для использования механизма бизнес-процессов и уведомлений для абонентов.
• IIS (Internet Information Services), встроенный компонент серверных ОС на платформе Windows Server, – как инструмент для того, чтобы развернуть внешний web-сервис.
• Postman – как инструмент для тестирования запросов.

Приступаем к реализации

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

Процесс занял некоторое время. От согласования с отделом бухгалтерии до финальной реализации прошло около двух недель.

Далее переходим к настройке документооборота и CRM-системы на платформе Битрикс24. Тут начинается самое интересное:

• При подключении нового абонента оператор со стороны 1С заполняет заявку на подключение, далее эта заявка попадает по протоколу REST в систему Битрикс24 и инициирует запуск бизнес-процесса, по которому задействуются нужные отделы и сотрудники (определение необходимости закупа оборудования, контроль оплат, распределение по командам монтажных бригад, финальный монтаж и подписание документов о передачи оборудования абоненту). После закрытия заявки абоненту приходит SMS-уведомление об успешном подключении к сервису. Заявка закрывается.
• При поступлении заявки от абонента об отключении от услуги или подключении к другому тарифу оператор вносит эти данные со стороны 1С. Далее заявка попадает в Битрикс24 на контроль в отдел бухгалтерского учёта и при отсутствии задолженности происходит распределение по монтажным бригадам, которая производит демонтаж и подписывает необходимые документы.
• Аналогичным образом настроены механизмы оповещений и обработки входящих заявок от абонентов. Автоматизированный расчёт стоимости происходит на стороне 1С. Если рассказать кратко, то при групповом формировании документов начисления для абонентов из базы 1С данные в Битрикс24 поступают через протокол RESTAPI. Далее  запускается бизнес-процесс системы оповещений через SMS о необходимости внесения оплат с контролем оплаты. В том случае, если от абонента не поступает реакции, разработана система уведомлений и, как крайний шаг, задача на отключение.

Далее переходим к интеграции с банковском ПО. После недолгих переговоров с местным отделением банка, в котором открыт счёт, пришли к соглашению. Банк
добавляет в приложение нашу компанию в список сервисов. При переходе абонент вводит свой ИИН и получает текущую сумму, которую нужно оплатить.

Запускаем web-сервис

На стороне 1С разработали HTTP-сервис, имеющий в себе два основных метода:

PostCustomersInfo – получает методом POST от банка информацию о успешной транзакции и вводе в базу 1С входящего платёжного поручения.

Содержание обработчика GetCustomerInfo в 1С:

Публикация web-сервиса ничем особым не примечательна, да и прошла без особых проблем. Вуаля, сервис работает.

Логика получилась следующая:

1. Абоненту поступило SMS-уведомление о необходимости оплаты.
2. Он переходит в приложение банка, вводит свой ИИН, получает сумму для оплаты, производит оплату.
3. В базу 1С попадет уже полностью заполненное платёжное поручение.

В логику проведения платёжного поручения внесён дополнительный исполняющий код, использующий фишку WebHooks от Битрикс24, позволяющую сместить стадию сделки в статус «Оплачено» и, соответственно, прекратить контроль оплаты по выставленной квитанции.

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

В итоге у нас есть:

1. Автоматизированная обработка поступающих заявок от абонентов.
2. Автоматизированный расчёт стоимости услуг и контроль оплат по ним.
3. Автоматизированная система приёма и разноски оплат в системе 1С Бухгалтерия.

А как вы автоматизируете процессы?

По данным журналистов, управление ведомства в курсе проблемы ещё с 2019 года. Но несмотря на это, никаких попыток исправить ситуацию с их стороны не исходит. А после того, как вся эта история была обнародована, департамент и вовсе заблокировал своим сотрудникам доступ к сайту KJZZ.

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

Источники радиостанции заявили, что они практически сразу же начали делать внутренние предупреждения IT-сотрудникам департамента. И до сих пор ведомство не исправило большую часть из них. Речь идёт в том числе о модулях, отвечающих за «отслеживание медицинского обслуживания заключенных, их количество, имущество, комиссионные и финансовые счета, религиозную принадлежность, классификацию безопасности и принадлежность к группировкам».

Источник: KJZZ

Описанная в этой статье стратегия автоматизации тестирования предполагает модель постоянной поставки с несколькими командами, работающими по методологии Agile.

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

Краткое содержание

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

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

Это требует «инвертирования пирамиды автоматизации тестирования» с отказом от GUI-тестов, которые занимают много времени, в пользу тестирования на более низких уровнях, например, API, где автоматические тесты можно запустить сразу после unit-тестов как часть сборки, чтобы обеспечить базовый уровень надёжности.

Обзор стратегии автоматизации тестирования

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

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

Как уже упоминалось, быстрое информирование разработчиков о состоянии приложения имеет огромное значение при непрерывной поставке, следовательно, надо найти механизм, которые позволит быстро давать обратную связь. Один из способов — увеличить количество unit-тестов, интеграционных тестов и тестов API. Эти низкоуровневые тесты формируют сеть безопасности, которая помогает убедиться, что приложение работает так, как было задумано, и позволяет предотвратить дефекты, возникающие на других уровнях тестирования. Unit-тесты служат основой для автоматизации тестирования на более высоких уровнях.

Вторая возможность для улучшения работы — запускать регрессионные тесты чаще и в параллели с непрерывной поставкой, об этом позже. Автоматизированное тестирование должно быть не изолированной задачей, а непрерывным процессом, неотъемлемо вписанным в жизненный цикл ПО.

Регрессионное тестирование

Автоматические регрессионные тесты — основа стратегии автоматизации тестирования.

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

Цель этого пакета тестов в том, чтобы отловить наиболее очевидные проблемы, например, то, что приложение не загружается или не запускается основной поток взаимодействия пользователя с приложением. Поэтому «дымовые» тесты не должны продолжаться больше 5 минут, их цель — сообщить, что не работает что-то ключевое.

Такие тесты запускаются при каждом развёртывании приложения и могут содержать как API, так и GUI-тесты.

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

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

Эти пакеты должны запускаться в различных окружениях по мере необходимости и проверять, что поведение приложения остаётся неизменным вне зависимости от окружения. Такие тесты запускаются несколько раз в день и должны продолжаться не дольше 15-30 минут.

Поскольку эти тесты более детализированы и занимают больше времени, важно выносить большую часть функциональных тестов на уровень API, где тестирование проходит быстрее. Это нужно для того, чтобы не выходить за временные рамки в 15-30 минут.

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

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

Такие тесты в основном проводятся с использованием GUI, поскольку они проверяют, как пользователь будет взаимодействовать с системой. Время, которое на них затрачивается, может варьироваться в зависимости от приложения, но обычно такие тесты запускаются один раз за день или за ночь.

Стратегия автоматизации тестирования для нескольких Agile-команд

Автоматизированные unit-тесты

Автоматизация тестирования начинается на уровне unit-тестов. Эти тесты должны создаваться для каждой новой возможности, находящейся в разработке. Именно они ложатся в основу более широкой практики автоматизации вплоть до системных GUI-тестов. Разработчики обязаны убедиться в том, что для каждой новой функциональной возможности разработан полный набор надёжных unit-тестов, позволяющих проверить, что код работает как задумано и отвечает всем требованиям. Unit-тесты наиболее выгодны с точки зрения окупаемости, поскольку их недолго написать, легко поддерживать и изменять (благодаря тому, что нет зависимостей), так что если в коде есть ошибка, то разработчик быстро узнает о ней. Unit-тесты должны запускаться как на компьютере разработчика, так и в среде непрерывной интеграции.

Автоматическая интеграция / API-тесты или сервис-тесты

В то время как unit-тесты основаны на тестировании функций внутри класса, интеграционные тесты формируют следующую ступень, направленную на тестирование классов, образующих компонент, входящий в состав нового функционала. Такие тесты запускаются только после того, как unit-тестирование было успешно завершено.

Сервис-тесты обычно запускаются на уровне API без вовлечения GUI-интерфейса, следовательно, тесты направлены на проверку функциональности в чистом виде, а поскольку тесты непосредственно обращаются к компонентам, они быстро проводятся и могут быть частью сборки. При необходимости тестирования взаимодействия с внешними сервисами, в случае, если внешние сервисы не доступны либо не могут гарантировать предоставление данных, отвечающих условиям тестирования, можно использовать эмуляторы внешних сервисов, например WireMock. API-тесты и/или сервис-тесты могут запускаться на компьютере разработчика или быть частью сборки, но если они начинают занимать длительное время, лучше запускать их в среде непрерывной интеграции. Для сервис-тестов можно использовать такие инструменты, как SoapUI.

Тесты приложения

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

Чтобы протестировать приложение в целом, обычно требуется интерфейс для взаимодействия между различными его компонентами, а значит, тестирование лучше проводить с использованием браузера или GUI. Цель этих тестов — убедиться в том, что приложение работает корректно. Такие тесты называют “вертикальными”, т.к. они направлены на проверку работоспособности конкретного приложения или компонента, а не всей системы целиком. Эти тесты отличаются глубиной проработки и большим объёмом.

Для проведения таких тестов в браузере можно использовать Selenium WebDriver. Этот инструмент является наиболее популярным для проведения автоматизированного тестирования в браузерах и предоставляет богатые возможности API для проведения сложных проверок.

Полные сценарные тесты

Автоматизированные GUI-тесты, которые запускаются для всей системы, используются как типичные пути пользователей или полные сценарии взаимодействия. Из-за проблем с этим типом тестов (описанных ниже) их количество лучше сократить до минимума. Полные сценарии включены в ночные регрессионные пакеты.

Инвертирование пирамиды автоматизации тестирования

В рамках стратегии автоматизации тестирования нам необходимо минимизировать количество автоматизированных тестов на уровне GUI.

Несмотря на то, что проведение автоматизированного GUI-тестирования даёт хорошие и значимые результаты с точки зрения симуляции пользовательского взаимодействия с приложением, оно имеет и ряд своих недостатков:

1. Хрупкость — для определения веб-элементов для взаимодействия тесты используют html-локаторы, поэтому как только меняется уникальный ID какого-либо элемента интерфейса, тесты перестают работать, а это влечёт за собой значительные расходы на поддержку.
2. Ограниченное тестирование — GUI может не позволить тестировщику полностью проверить функциональность,  поскольку он не всегда содержит все детали веб-ответа, необходимые для верификации.
3. Низкая скорость — поскольку тесты проводятся через GUI, время загрузки страницы существенно увеличивает общее время тестирования, и обратная связь разработчикам поступает значительно позже.
4. Наименьшая окупаемость — из-за всех проблем, перечисленных выше, GUI-тесты становятся наименее целесообразными с финансовой точки зрения.

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

За перевод выражаем благодарность международной IT-компании Noveo