Автотестирование в SimpleOne: как перестать бояться обновлений

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

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

Эта статья — краткий конспект вебинара. Далее мы разберем специфику контроля качества в кастомизированных системах, современные подходы к автоматизации и практические сценарии применения JESM. Запись мероприятия смотрите на странице вебинара.

Когда кастомизация становится риском

При активном развитии системы у команд возникают типичные вопросы:

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

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

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

Как внедрять новое и не ломать старое? Скорость внедрения важна, но не в ущерб стабильности того, что уже работает в продуктиве.

Чтобы ускорять внедрение изменений без риска для продуктивной среды, команда Outsorsa разработала JESM — самостоятельную продуктовую экосистему модулей, которая интегрируется с SimpleOne и расширяет контур управления тестированием, изменениями и качеством релизов.

JESM: что это и как работает

JESM Автоматизация Тестирования — это модуль, который разворачивается как отдельный инстанс и подключается к одному или нескольким инстансам платформы: Dev, Test, Preprod, Prod.

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

Возможности JESM:

• Двусторонняя синхронизация с SimpleOne — дефекты создаются прямо в нужной таблице платформы: в кастомной таблице, в инцидентах ITSM или в приложении SDLC. Если в SimpleOne меняется статус записи, JESM получает триггер и реагирует.

• JESM находит и проверяет, человек исправляет. Решение самостоятельно прогоняет тесты, фиксирует, что сломалось, создаёт дефект с логом и скриншотом, а затем ждёт. Когда разработчик исправил проблему и поменял статус дефекта, JESM сам перезапускает тест и проверяет результат. Человеку не нужно помнить, что надо перетестировать, и вручную запускать прогон.
• Генерация тестов через ИИ — можно описать сценарий на человеческом языке, ИИ сгенерирует готовый тест. Поддерживаются OpenAI-совместимые сервисы, включая Яндекс и модели, развернутые самостоятельно.
• Поддержка нескольких окружений — один инстанс JESM может тестировать несколько инстансов SimpleOne одновременно.

Кейс 1. ESM из коробки — дефекты в кастомной таблице

Что проверяли: обновление данных о конфигурационной единице.

Что сломалось: Запись не сохранялась. В логе было видно, что поля изменены, но сохранение не произошло. 

Что сделали мы: открыли скриншот из результатов теста в JESM и увидели, что поле Owner на записи КЕ стало обязательным. Кто-то изменил клиентский скрипт в SimpleOne — поле Owner стало обязательным, из-за чего форма не сохранялась. Скрипт нашли и исправили, а затем перевели автоматически созданный дефект в статус «Готово»‎.

Что сделал JESM: получил триггер об исправлении дефекта и автоматически перезапустил тест. Успешность 100%.

Кейс 2. ITSM — дефекты как инциденты

Что проверяли: полный цикл запроса на установку и обновление ПО на портале.

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

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

Что сделал JESM: получил триггер от закрытого инцидента, автоматически перезапустил тест. На этот раз запрос прошёл полный цикл — создание, согласование, смена статусов. Успешность 100%.

Кейс 3. SDLC — дефекты в приложении и генерация тестов через ИИ

Что проверяли: наличие кнопки Print Form на форме запроса на обслуживание под определённым пользователем.

Что сломалось: JESM зашёл под нужным пользователем и не нашёл кнопку. Создал дефект в приложении SDLC с логом и скриншотом. На скриншоте видно, что кнопка для этого пользователя скрыта.

Что сделали мы: нашли ограничение видимости кнопки, исправили его, перевёли задачу в SDLC в статус «Готово».

Что сделал JESM: получил триггер, перезапустил тест, подтвердил что кнопка теперь видна. Успешность 100%.

Дополнительно в этом кейсе показали генерацию теста через ИИ. Написали промт: «Проверь наличие кнопки с текстом Print Form на форме записи первого Request, используя встроенные методы». JESM сгенерировал готовый тестовый сценарий. Мы подставили только нужного пользователя — два клика, никакого кода.

Кейс 4. Change Management — как проверить изменение процесса на каждом стенде

Этот кейс не про поиск бага, а про внесение изменения в живой процесс. 

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

Просто поменять на проде нельзя — процесс живой. Изменение нужно провести через цепочку Dev→Test→Prod, и на каждом стенде убедиться что всё работает как ожидается.‎

Что сделали мы: 

1. Представили, что деятельность выполняется на разных стендах, а для демонстрации выполняли все действия на одном стенде.
2. Создали ЗНИ на портале, провели его через согласование → автоматически создалась задача для стенда Dev.
3. Внесли изменение в workflow — поменяли поле согласующих.
4. В JESM скорректировали тестовый сценарий: указали, что ожидаемое количество согласующих теперь равно одному.
5. Перевели задачу на Dev в статус «Завершена».

Что сделал JESM:

1. Получил триггер о смене статуса на задаче ЗНИ для Dev стенда.
2. Автоматически создал тестовый ЗНИ на стенде Dev, провёл его по полному циклу согласования и проверил, что активное согласование только одно.
3. Провел тестирование и зафиксировал итоги.
4. Автоматически подтвердил выполнение задачи и создал задачу для переноса настроек на Test инстанс и проверке аналогично Dev.
5. После переноса и проверки создал задачу в изначальном ЗНИ на перенос конфигурации в Prod.

Итог: Cтенды протестированы без ручных запусков, изменение вышло на прод с подтверждением, что всё работает корректно.

Итоги

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

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