У любого процесса есть своё бутылочное горлышко. Если разобрать его на одной стадии процесса, оно непременно появится на другой. Но одно бутылочное горлышко может соответствовать максимальной эффективности команды, а другое будет тормозить поставку вашей ценности заказчику. При этом заранее угадать на старте проекта, где будет ваше бутылочное горлышко — очень сложно.
Мы расскажем, как искали путь выхода из подобной ситуации. Почему при достаточном соотношении QA и DEV-инженеров в команде у нас сформировалось бутылочное горлышко на стадии тестирования. Как обсуждения пирамиды тестирования и распределения зон ответственности за качество продукта помогли избавиться от недоверия в команде и ускорить поставку ценности.

Будет полезно тем, кто ищет реальные кейсы по оптимизации процессов тестирования и хочет узнать, как построить работающий QA-процесс в условиях ограниченных ресурсов и быстро меняющихся требований.

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

Пришлось потратить пару/тройку часов, нахватать минусов, не понятно за что.
Чтобы провести тесты и получить результат — при старте новой Activity с передачей 1000 объектов с 4 полями, прирост производительности в 4 раза Parcelable по отношению к Serializable.
Вот, чего я спрашивал. Но ни кто мне этого сказать так и не смог.