Low-code-платформа: подводные камни
Челлендж: как без тысячи строк кода создать систему управления предприятием?? В 2022 году работали над подобной задачей — создавали Low-code-UI-конструктор 🤓  

Это не первый такой проект, так что мы понимали:
1️⃣ Важно смотреть на платформу с точек зрения двух групп пользователей, которые будут:
▪️ с её помощью создавать конечный продукт.
▪️ непосредственно работать с этим продуктом.
Механизмы работы платформы должны быть максимально абстрактными, чтобы закрыть как можно больше кейсов использования системы.    
2️⃣ Нужно начинать работу с MVP. При этом в нашем случае даже MVP содержала объёмный набор функций, и обойтись без них было нельзя — иначе не решить задачи пользователей и не получить от них обратную связь для дальнейшего развития.
3️⃣ Нужно разбить продукт на несколько более мелких частей или релизов, чтобы чаще выпускать стабильные версии и обновления.

Тем не менее при разработке мы столкнулись с такими препятствиями:
▪️ Нужны интеграционные тесты в большом количестве. И они не всегда очевидны из аналитики.
▪️ Много тестовой документации, которую нужно обновлять. При этом компоненты сложной системы взаимосвязаны — одно изменение влечёт за собой другое.
▪️ О недостающих критичных фичах мы продолжали узнавать в процессе разработки. Это связано с масштабом системы, широким спектром компонентов и подсистем.
▪️ Большое количество микросервисов в продукте влияет и на проработку архитектуры.

❗️ То есть нужно заранее учитывать и предугадывать множество взаимосвязей и интеграций. Сложность тестирования оказалась в том, что конструктор имеет огромное количество комбинаций, которыми можно воспользоваться. Прописать в аналитике исчерпывающие сценарии использования невозможно. Уже к сдаче MVP мы поняли, что нужно менять подход к тестированию. Мало просто проанализировать целевую аудиторию, нужно покрыть все требования тестами, применить техники тест-дизайна.

В итоге мы пришли к таким решениям:
1️⃣ Проанализировали все баги и узкие места, которые возникали при использовании системы в промежуточном тестировании, и выявили часто повторяющиеся комбинации и проблемы. Все проверки включили в регресс.
2️⃣ Воспользовались техникой попарного тестирования и составили максимально возможное количество комбинаций между элементами интерфейса, доступными действиями и событиями.
3️⃣ После общения с заказчиком о задачах той или иной фичи и анализа бизнес-логики системы прописали основные интеграционные тесты.
4️⃣ Поскольку без автоматизации тестирования невозможно быстро выпускать релизы, мы разделили процесс на этапы, чтобы снизить затраты и повысить эффективность. Совместно с заказчиком определили основные критичные сценарии, которые нужно проверять каждый раз при внесении правок в систему. Это позволило нам уже на самом начальном этапе запускать автотесты и покрывать критичный функционал, быстрее «заливать» хотфиксы или срочные доработки.