Решения · Argus QA

Автономное регрессионное тестирование для телеком-операторов

Автономное регрессионное тестирование для телеком-операторов. Операторы обрабатывают миллионы обращений абонентов на азербайджанском и русском языках при жёстких SLA по качеству обслуживания.

Автономное регрессионное тестирование корпоративных веб-приложений

Телеком-операторы обрабатывают миллионы обращений абонентов на азербайджанском и русском языках, удерживая жёсткие SLA по качеству обслуживания. Любой необнаруженный дефект в биллинге, личном кабинете или системе обработки заявок напрямую влияет на отток абонентов и репутацию оператора. Argus — самостоятельно развёртываемая AI-платформа тестирования в составе продуктовой линейки Allmaz — запускает автономных агентов, которые проверяют сложные многоролевые сценарии в корпоративных веб-приложениях без жёсткой привязки к селекторам или координатам. Сценарии описываются как версионированные YAML-объективы с ролью, утверждениями и бюджетом шагов и времени: агент сам определяет путь по скриншоту, рассуждает вслух и выполняет одно действие за ход, а каждый шаг сохраняется независимо от результата.

Возможности

Почему Argus важен для телеком-операторов

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

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

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

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

Безопасность данных и отсутствие внешних зависимостей: платформа разворачивается в десяти контейнерах на собственной инфраструктуре оператора. Никаких внешних SaaS-сервисов — данные абонентов и учётные записи не покидают периметр. Смена AI-модели вступает в силу на следующем запуске без повторного развёртывания.

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

Ключевые возможности платформы

Сценарии на основе целей, а не селекторов

Тест-кейсы описываются как версионированные YAML-объективы с ролью, утверждениями и бюджетом шагов и времени — без координат и CSS-селекторов. Агент наблюдает скриншот, формулирует рассуждение и выполняет одно действие за ход; каждый шаг сохраняется независимо от результата.

Многоролевые рабочие процессы в изолированных сессиях

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

Параллельные прогоны без коллизий данных

Тестовые данные именуются в рамках конкретного прогона, поэтому несколько агентов могут одновременно работать в общей среде — критично при параллельных проверках биллинговых и CRM-систем оператора.

Независимая верификация утверждений

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

Маршрутная память и адаптивное руководство

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

Единая конфигурация для QA, AI и пентест-движков

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

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

1QA-инженер описывает сценарий в веб-интерфейсе: роль (например, «оператор контакт-центра»), цель («оформить заявку на смену тарифа»), утверждения и бюджет шагов. Сценарий валидируется по схеме при сохранении — ошибки конфигурации выявляются до запуска.
2Платформа запускает агента в изолированной браузерной сессии. Вход выполняется детерминированным скриптом через зашифрованное хранилище секретов — агент получает уже аутентифицированную сессию и не имеет доступа к учётным данным напрямую.
3Агент наблюдает скриншот, формулирует рассуждение и выполняет одно действие за ход. Для многоролевых сценариев каждая роль работает в своей независимой сессии параллельно или последовательно в зависимости от логики процесса.
4Каждый шаг фиксируется: действие, скриншот, результат. Независимый верификатор проверяет утверждения. При сбое система классифицирует его по одной из семи категорий: дефект продукта, ошибка агента, ошибка окружения, ошибка утверждения, зацикливание, превышение лимита шагов или таймаут.
5При обнаружении вероятного дефекта продукта агент формирует готовый к подаче отчёт с контекстом и скриншотами. Инженер рассматривает отчёт и принимает решение о регистрации бага — система не утверждает дефект самостоятельно.
6Стоимость каждого вызова модели агрегируется от шага до сценария, набора и релиза. Каждый прогон фиксирует билд-метку тестируемой среды, что позволяет команде отслеживать динамику качества и затрат в разрезе каждого релиза.

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

Подходит ли платформа для интерфейсов на азербайджанском языке?

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

Как платформа защищает учётные данные абонентов и операторов?

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

Заменяет ли Argus существующие скриптовые тесты на Playwright?

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

Каковы ориентиры по стоимости и автономности?

На тестовом наборе из 25 сценариев, включая 8 многоролевых, на живой платформе управления контрактным жизненным циклом около 70% сценариев, не заблокированных реальными дефектами приложения, завершились автономно, а три реальных продуктовых дефекта были обнаружены независимо. Стоимость полного прогона составила от 0,4 до 2,3 доллара. Это измеренные показатели текущего этапа продукта, а не гарантии уровня сервиса.

Можно ли изменить AI-модель без повторного развёртывания?

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

Как классифицируются сбои и кто принимает решение о дефекте?

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