Для генерации тестовых данных, если не ошибаюсь, в минимальной конфигурации достаточно:
1. словарей данных (имена, фамилии, отчества, компоненты адреса)
2. правил создания синтетических данных (семьи из имен и правил рождения, адреса, синтезированные данные банковских документов и т.п.
Верно, этого вполне достаточно для генерации простых связанных данных. Но для реальных кейсов нужны связи, в которых участвуют десятки сущностей (услуги, счета, сервисы в заданных состояниях), которые создаются не просто в плоском списке, а в самостоятельных автоматизированных системах (АС). Создание таких сущностей можно инициировать только через обращение по API к соответствующей АС в тестовом контуре.
Вы пишете, что для создания правил и генерации синтетических данных потребуется больше года и работа будет впустую?
Я понимаю, что Сберу виднее, но на мой взгляд:
1. создание правил вместо AI модели дает больше контроля над генерируемыми данными
2. как следствие - данные на основании правил лучше подходят для аккуратных тестовых сценариев например: сгенерить адреса для урюпинска, сгенерить большие семьи, где 1+ grands и 3+ детей
Основной вопрос: правила или AI model?
Согласен, это рациональный подход к генерации тестовых данных в виде плоских таблиц. Кстати, такие генераторы применяем для предзаполнения полей-входных данных при тестах. Но наш кейс про то, что тестовые данные генерятся в разных АС (т.е. АС в тестовом контуре переходят в нужные состояния, там появляются нужные нам сущности). На выходе получаем набор артефактов от этих АС в виде тех самых плоских таблиц. Да, мы могли бы сгенерить их по правилам или с помощью ML-модели, но это не решает вопрос заведения нужных сущностей в АС не тестовых контурах.
А для случая когда тестировщику не нужна подготовка АС можно написать правила для всех АС в тестовых контурах и генерить данные точно также как генерят сами АС. Проблема в том, что одна АС = один продукт со своей продуктовой командой и своим релизным циклом. С каждым релизом есть риск изменений логики, что требует актуализации написанных ранее правил. А это очень ресурсоемко.
Верно, этого вполне достаточно для генерации простых связанных данных. Но для реальных кейсов нужны связи, в которых участвуют десятки сущностей (услуги, счета, сервисы в заданных состояниях), которые создаются не просто в плоском списке, а в самостоятельных автоматизированных системах (АС). Создание таких сущностей можно инициировать только через обращение по API к соответствующей АС в тестовом контуре.
Согласен, это рациональный подход к генерации тестовых данных в виде плоских таблиц. Кстати, такие генераторы применяем для предзаполнения полей-входных данных при тестах. Но наш кейс про то, что тестовые данные генерятся в разных АС (т.е. АС в тестовом контуре переходят в нужные состояния, там появляются нужные нам сущности). На выходе получаем набор артефактов от этих АС в виде тех самых плоских таблиц. Да, мы могли бы сгенерить их по правилам или с помощью ML-модели, но это не решает вопрос заведения нужных сущностей в АС не тестовых контурах.
А для случая когда тестировщику не нужна подготовка АС можно написать правила для всех АС в тестовых контурах и генерить данные точно также как генерят сами АС. Проблема в том, что одна АС = один продукт со своей продуктовой командой и своим релизным циклом. С каждым релизом есть риск изменений логики, что требует актуализации написанных ранее правил. А это очень ресурсоемко.