Решения · Argus QA

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

Автономное регрессионное тестирование для банков. Банки работают под надзором Центрального банка Азербайджана и в режиме банковской тайны, поэтому данные клиентов не могут уходить в зарубежные облака.

Автономное регрессионное тестирование для банков — внутри вашего периметра

Банки под надзором Центрального банка Азербайджана обязаны соблюдать требования банковской тайны и локализации данных: клиентские данные, скриншоты и артефакты тестирования не могут покидать внутреннюю инфраструктуру. Argus — самостоятельно размещаемая платформа AI-тестирования, которая разворачивается в десяти контейнерах и общем томе артефактов исключительно внутри периметра банка. Платформа не имеет зависимостей от внешних SaaS-сервисов: модели, учётные данные, тарификация и настройки развёртывания конфигурируются один раз для всех трёх движков — регрессионного тестирования, AI-анализа и пентеста — и остаются под полным контролем банка. Это обеспечивает соответствие регуляторным требованиям без компромиссов в части функциональности.

Возможности

Что это даёт банку

✓

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

✓

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

✓

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

✓

Контроль стоимости AI-вычислений: каждый вызов модели тарифицируется, затраты агрегируются от шага до релиза; двухуровневое исполнение — сначала экономичная модель, эскалация на более мощную только при сбое агента — позволяет удерживать стоимость полного прогона набора из 25 сценариев в диапазоне $0,4–2,3.

✓

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

✓

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

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

Self-hosted развёртывание без внешних зависимостей

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

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

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

Полная доказательная база для регулятора

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

Классификация сбоев и независимая верификация

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

Интеграция с Qase и Jira без потери контекста

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

Гибкое управление моделями без переразвёртывания

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

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

1Платформа разворачивается внутри инфраструктуры банка: десять контейнеров, общий том артефактов, настройка моделей, учётных данных и тарификации один раз для всех трёх движков. Одно развёртывание обслуживает несколько сред — каждая со своим базовым URL, шагами входа и учётными записями по ролям.
2Сценарии описываются как версионированные YAML-цели с ролью, утверждениями и бюджетами шагов и времени — без селекторов и координат. Сценарии, наборы и общий файл заметок о приложении редактируются из веб-интерфейса и валидируются при сохранении по схеме самого раннера.
3Каждая роль — например, операционист, согласующий, контролёр — запускается в отдельной, независимо аутентифицированной браузерной сессии. Вход выполняется детерминированным скриптом через зашифрованное хранилище секретов; агент никогда не видит учётные данные. Именование тестовых данных в рамках прогона позволяет параллельным агентам работать в общей среде без конфликтов.
4Агент наблюдает скриншот, формулирует рассуждение и выполняет одно действие за ход; каждый шаг сохраняется вне зависимости от результата. Утверждения проверяет независимый верификатор. Сначала работает экономичная модель; при сбое на стороне агента выполняется одна попытка эскалации на более мощную модель.
5По завершении прогона сбои классифицируются по типу; подозреваемый дефект продукта формирует готовый отчёт — сотрудник QA проверяет его и подаёт в Qase или Jira. Каждый прогон фиксирует метку сборки тестируемой среды и того, кто его запустил. ИИ не фиксирует дефект самостоятельно.
6Наборы запускаются по расписанию — например, ночью; прогон, обнаруживший занятую среду, откладывается, а не теряется. Прогоны можно искать, сравнивать с предыдущими, отслеживать в живой консоли и анализировать тренды по завершению, стоимости и сбоям в разрезе релизов.

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

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

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

Может ли ИИ самостоятельно зафиксировать дефект или подать отчёт?

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

Как платформа справляется с многоролевыми банковскими процессами — например, согласованием кредита или операциями взыскания?

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

Как контролируются затраты на AI-модели и можно ли сменить модель без остановки системы?

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