На вебинаре наш коллега Алексей разобрал 4 живых кейса — от простого к сложному. Рассказываем, куда JESM умеет создавать дефекты и откуда получать сигналы на перезапуск.
Сценарий 1. Только коробка ESM
— Дефект попадает в кастомную таблицу SimpleOne (не конкурирует с SDLC), которая идет вместе с JESM.
— Починили дефект → перевели в статус «Готово» → JESM перезапускает тест автоматически.
✔️Итог: минимальный вход, без лишних приложений.
Сценарий 2. Приложение ITSM (инциденты)
— Упал тест → создается инцидент в SimpleOne ITSM.
— Закрыли инцидент → тест перезапустился → успех 100%.
✔️Итог: тестирование через привычный ITSM справочник.
Сценарий 3. Приложение SDLC (дефекты)
— Дефект создается прямо в таблице дефектов SimpleOne SDLC.
— Починили дефект → перевели в статус «Готово» → JESM перезапускает тест автоматически.
✔️Итог: привычная среда приложения SDLC.
Сценарий 4. Change Request (самый мощный)
— Создаем запрос на изменение с целью правки процесса согласования не по полю "Ответственные", а по полю "Владелец".
— Создается последовательная цепочка задач для выполнения действий в рамках рабочего процесса для каждого стенда (Dev → Test → Prod).
— JESM следует за рабочим процессом и тестирует Dev → Test → Prod(если необходимо).
— Автоматически создаются задачи на стенды, автотесты стартуют при смене статусов задач запроса на изменение.
✔️Итог: полная цепочка управления изменениями с контролем качества.
«Вы можете настроить триггер на перенос пакета между окружениями — и JESM сам запустит тестирование на целевом стенде. А на прод выводите только то, что уже прошло все проверки»
Напишите нам, покажем JESM в работе
📧 info@outsorsa.ru
#SimpleOne #JESM #CI CD #ChangeManagement #Тестирование #Автотесты #LowCode #ПрощеНекуда