Динамическая регрессионная модель: как сделать так, чтобы регресс не съел все ваши ресурсы
К хорошему быстро привыкаешь, причём иногда настолько быстро, что кажется, будто какая-то полезная штука с тобой уже чуть ли не всю жизнь. С дистанционным банковским обслуживанием такая же история: по ощущениям ДБО — это уже чуть ли не стандарт, который обязательно должен быть у всех. Хотя на самом деле эта опция не так давно отметила десятилетие. За все годы развития ДБО постоянно обрастало новыми возможностями: сначала можно было просто оставить заявку на открытие счёта, затем открыть сам счёт, оформить дебетовку (а потом и кредитку). Сейчас так же просто можно оформить ипотеку или взять срочный кредит.
В общем, ДБО — это про удобство и комфорт. Если какой-то банк сейчас начнёт сокращать перечень услуг, доступных дистанционно, то с большой долей вероятности сокращаться начнёт и число его клиентов. Поэтому ДБО должно быть, и быть работоспособным, безопасным, и не глючить.
Отдельно тут можно отметить пандемию, когда в условиях карантина и удалёнки популярность ДБО многократно возросла. Мы в МКБ в это время потихоньку готовили ряд новых возможностей и планировали выкатывать их постепенно, но надо было подстраиваться под новую реальность и форсировать процесс. Сейчас наша система обслуживания клиентов построена так, что человек де-факто может посетить офис МКБ лишь один раз, после чего ему в дистанционном формате будет доступен весь спектр наших банковских услуг. Причём что в мобильных приложениях, что в веб-версии — объём функций практически идентичен.
Но этого поста бы не было, если б на пути ускоренного расширения функциональности мы не встретили его — стремительно растущий набор регрессионных кейсов.
В этом посте я хочу рассказать, как мы наладили регрессионное тестирование, на примере собственно ДБО, а также одного из важнейших столпов качественного дистанционного обслуживания — нашей CRM.
О важности удобной CRM
Само собой, в банке CRM — это не просто инструмент для работы с клиентами, а платформа, которая постоянно дорабатывается и улучшается, ведь появляются новые банковские продукты, меняются старые, обновляется законодательство — в общем, не соскучишься. И в плане взаимодействия CRM является основной точкой входа для ДБО, а также мастер-системой по клиентским данным.
Наш главный фокус в отношении CRM — чтобы с системой было удобно работать сотрудникам, которые непосредственно взаимодействуют с клиентами банка. Можно сказать, что эти люди выступают в качестве нашего внутреннего заказчика. И если CRM будет тупить, тормозить и просто вылетать время от времени, то неудобство будут испытывать все: и наши коллеги, и наши клиенты, а в конечном итоге и бизнес, так что наша задача – сделать CRM максимально стабильной и удобной.
Кстати, CRM меняется и дорабатывается не только из-за обновлений продуктов или законодательства: система сама по себе довольно объёмная, в ней работает сразу несколько подразделений банка. Операционисты, колл-центр и иные внутренние подразделения — все сидят в ней. И когда вносишь изменения в такую большую систему с внушительным количеством взаимосвязей, хотя бы минорные ошибки становятся почти неизбежными.
В таких случаях есть два варианта действий. Первый — это просто позволить себе выпускать функционал с каким-то количеством багов, которые можно допилить потом. В нашем случае это неприемлемо, потому что мы банк, а банк — это и про деньги, и про доверие. Работа с финансами всегда влечёт повышенную ответственность, особенно если мы говорим о пользовательском опыте. Скажем, когда человек из-за ошибки на стороне банка не смог что-то оплатить, его реакция будет ожидаемо негативной. И справедливой.
Второй вариант, собственно наш, — это находить ошибки ещё в ходе разработки. А лучший способ убедиться, что новые фичи не привнесли неприятный сюрприз в существующие функции системы, — регрессионное тестирование.
Как мы тестируем CRM и ДБО
Как в случае с CRM, так и в случае с ДБО над доработкой системы работают сразу несколько команд, каждая из которых сосредоточена на развитии своего бизнес-направления. Например, одна команда сфокусирована на нецелевых кредитах, другая — на карточных, третья — на вкладах и счетах и так далее.
Прежде всего, мы тестируем новый функционал. Подробно на этом этапе останавливаться не буду, предлагаю перейти к моменту, когда по каждой из задач успешно прошли функциональные тесты.
Обязательный этап — приёмочное пользовательское тестирование нового функционала. Здесь мы или демонстрируем реализованные фичи в удобном заказчику формате (это может быть онлайн-демонстрация работы системы, скриншоты, видео), или даём возможность коллегам из бизнеса зайти на тестовый контур и пощупать всё самостоятельно. Так они могут убедиться, что всё работает именно так, как они себе и представляли. После этого можно считать, что задача готова к переносу на продакшен.
Казалось бы, конец истории. Но, к сожалению, не всё так просто.
Наши разработчики — действительно профессионалы и отличные ребята, но все варианты использования модифицированного кода учесть просто невозможно. В итоге новая доработка условной команды 1 может зааффектить существующую функциональность, за которую отвечает команда 2. Команда 2, разумеется, даже не подозревает о том, что вверенная ей функциональность претерпела изменения, и проверять её не станет. При этом есть вероятность, что бизнес-процесс команды 2 будет нарушен.
Ситуацию спасёт регрессионное тестирование!
Но у регрессионного тестирования есть пара подводных камней.
К примеру, всегда есть соблазн взять скопом вообще все функции системы и сказать, что это — наша регрессионная модель. А значит, перед каждым новым обновлением (даже маленьким и точечным) будем проверять абсолютно все функции, которые существовали до внедрения. С одной стороны, это здорово: так точно можно убедиться, что обновление не затронет вообще ничего лишнего и всё будет работать. С другой — для такого подхода нужно колоссальное количество времени и сил.
Как же сохранить пользу регресса, не скормив ему все ресурсы команды тестирования?
Один из вариантов решения проблемы — автоматизация тестирования. И, само собой, мы стараемся максимально автоматизировать регрессионные проверки. Однако не всегда есть возможность автоматизировать всё и сразу. В случае стремительно изменяющегося дизайна или при использовании в тестовом сценарии нескольких разношёрстных бэковых систем автоматизация будет либо существенно отставать от потребности команд, либо потребует довольно серьёзных трудозатрат.
Мы пришли к выводу, что оптимальной для нашей ситуации будет динамически наполняемая регрессионная модель. Если точнее, то динамически наполняемый набор регрессионных кейсов для каждого конкретного релиза.
Вот как всё работает.
У нас есть набор тестовых сценариев по всей системе. Он пополняется буквально после каждого релиза, добавляются новые проверки, которые и составляют полную регрессионную модель. Из этой полной модели отбирается часть основных проверок, которые покрывают базовую функциональность системы. Если эти проверки по каким-то причинам не проходят, значит, где-то не работает базовая функциональность системы, и выпускать релиз нельзя. Состав этой базы каждая команда определила вместе со своим бизнес-заказчиком. Этот набор проверок обязателен и неукоснительно выполняется перед каждым релизом.
Оставшиеся кейсы мы разбиваем на модули, конкретные области функционала. В список финальных проверок перед релизом попадают только проверки тех модулей, которые могли быть затронуты добавляемыми фичами. «Круг подозреваемых» формируется как на основании экспертной оценки самой команды тестирования, аналитики и разработки, так и по информации от смежных команд.
Кроме этого, мы проводим все автоматизированные проверки, так как их применение очень дёшево обходится с точки зрения трудозатрат. Проверить, отработали ли автотесты, довольно просто, это не доставляет каких-то проблем.
Обновления происходят раз в две недели — довольно распространённый релизный цикл. Чаще всего в релизы уходят бизнес-задачи, но иногда и просто небольшие фиксы, закрывающие техдолг или баги, о которых конечный пользователь мог и не догадываться. Внедрение бизнес-задач планируется заранее — бизнес передаёт свои пожелания и свежие идеи в IT, а IT-команды начинают работать с этими требованиями по стандартному циклу разработки ПО. Формируются технические требования, проходит разработка и полный цикл тестирования. Матричная операционная модель и командный подход позволяют делиться и реализовывать задачи бизнес-подразделения по полному циклу тестирования.
Планы на будущее
Хоть сейчас описанный процесс и выглядит логичным, и вполне нас устраивает, всегда есть к чему стремиться. В общем и целом, описанный подход использования регрессионной модели кажется мне оптимальным. Но есть и недостатки: иногда бывает недостаточно информации о влиянии на модули системы, что в этом релизе будет затронуто минимально, а что на самом деле важно проверить.
Риск применения неполного покрытия в том, что можно что-то упустить. Это не самая частая проблема, но всё же бывает. Хотя, как правило, при таком подходе до конечного пользователя доходят только минорные ошибки.
Но плюсы пока перевешивают: если сравнивать динамическую регрессионную модель со статической, то разница по трудозатратам ощутима. Например, в случае статической модели полное регрессионное тестирование могло бы занимать около 700+ человеко-часов. То есть команда из 15 человек сидит и больше недели только и делает, что занимается регрессионным тестированием. В таких условиях оперативно доставить какие-то полезные изменения до пользователя становится или слишком дорого и долго, или просто невозможно.
