К хорошему быстро привыкаешь, причём иногда настолько быстро, что кажется, будто какая-то полезная штука с тобой уже чуть ли не всю жизнь. С дистанционным банковским обслуживанием такая же история: по ощущениям ДБО – это уже чуть ли не стандарт, который обязательно должен быть у всех. Хотя на самом деле эта опция не так давно отметила десятилетие. За все годы развития ДБО постоянно обрастало новыми возможностями: сначала можно было просто оставить заявку на открытие счёта, затем открыть сам счёт, оформить дебетовку (а потом и кредитку). Сейчас так же просто можно оформить ипотеку или взять срочный кредит.

В общем, ДБО – это про удобство и комфорт. Если какой-то банк сейчас начнёт сокращать перечень услуг, доступных дистанционно, то с большой долей вероятности сокращаться начнёт и число его клиентов. Поэтому ДБО должно быть, и быть работоспособным, безопасным, и не глючить.

Отдельно тут можно отметить пандемию, когда в условиях карантина и удалёнки популярность ДБО многократно возросла. Мы в МКБ в это время потихоньку готовили ряд новых возможностей и планировали выкатывать их постепенно, но надо было подстраиваться под новую реальность и форсировать процесс. Сейчас наша система обслуживания клиентов построена так, что человек де-факто может посетить офис МКБ лишь один раз, после чего ему в дистанционном формате будет доступен весь спектр наших банковских услуг. Причём что в мобильных приложениях, что в веб-версии – объём функций практически идентичен.

Но этого поста бы не было, если б на пути ускоренного расширения функциональности мы не встретили его – стремительно растущий набор регрессионных кейсов.

В этом посте я хочу рассказать, как мы наладили регрессионное тестирование, на примере собственно ДБО, а также одного из важнейших столпов качественного дистанционного обслуживания — нашей CRM.

О важности удобной CRM

Само собой, в банке CRM – это не просто инструмент для работы с клиентами, а платформа, которая постоянно дорабатывается и улучшается, ведь появляются новые банковские продукты, меняются старые, обновляется законодательство – в общем, не соскучишься. И в плане взаимодействия CRM является основной точкой входа для ДБО, а также мастер-системой по клиентским данным.

Наш главный фокус в отношении CRM – чтобы с системой было удобно работать сотрудникам, которые непосредственно взаимодействуют с клиентами банка. Можно сказать, что эти люди выступают в качестве нашего внутреннего заказчика. И если CRM будет тупить, тормозить и просто вылетать время от времени, то неудобство будут испытывать все: и наши коллеги, и наши клиенты, а в конечном итоге и бизнес, так что наша задача ­– сделать CRM максимально стабильной и удобной.

Кстати, CRM меняется и дорабатывается не только из-за обновлений продуктов или законодательства: система сама по себе довольно объёмная, в ней работает сразу несколько подразделений банка. Операционисты, колл-центр и иные внутренние подразделения – все сидят в ней. И когда вносишь изменения в такую большую систему с внушительным количеством взаимосвязей, хотя бы минорные ошибки становятся почти неизбежными.

В таких случаях есть два варианта действий. Первый – это просто позволить себе выпускать функционал с каким-то количеством багов, которые можно допилить потом. В нашем случае это неприемлемо, потому что мы банк, а банк – это и про деньги, и про доверие. Работа с финансами всегда влечёт повышенную ответственность, особенно если мы говорим о пользовательском опыте. Скажем, когда человек из-за ошибки на стороне банка не смог что-то оплатить, его реакция будет ожидаемо негативной. И справедливой.

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

Как мы тестируем CRM и ДБО

Как в случае с CRM, так и в случае с ДБО над доработкой системы работают сразу несколько команд, каждая из которых сосредоточена на развитии своего бизнес-направления. Например, одна команда сфокусирована на нецелевых кредитах, другая – на карточных, третья – на вкладах и счетах и так далее.

Прежде всего, мы тестируем новый функционал. Подробно на этом этапе останавливаться не буду, предлагаю перейти к моменту, когда по каждой из задач успешно прошли функциональные тесты.

Обязательный этап – приёмочное пользовательское тестирование нового функционала. Здесь мы или демонстрируем реализованные фичи в удобном заказчику формате (это может быть онлайн-демонстрация работы системы, скриншоты, видео), или даём возможность коллегам из бизнеса зайти на тестовый контур и пощупать всё самостоятельно. Так они могут убедиться, что всё работает именно так, как они себе и представляли. После этого можно считать, что задача готова к переносу на продакшен.

Казалось бы, конец истории. Но, к сожалению, не всё так просто.

Наши разработчики – действительно профессионалы и отличные ребята, но все варианты использования модифицированного кода учесть просто невозможно. В итоге новая доработка условной команды 1 может зааффектить существующую функциональность, за которую отвечает команда 2. Команда 2, разумеется, даже не подозревает о том, что вверенная ей функциональность претерпела изменения, и проверять её не станет. При этом есть вероятность, что бизнес-процесс команды 2 будет нарушен.

Ситуацию спасёт регрессионное тестирование!

Но у регрессионного тестирования есть пара подводных камней.

К примеру, всегда есть соблазн взять скопом вообще все функции системы и сказать, что это – наша регрессионная модель. А значит, перед каждым новым обновлением (даже маленьким и точечным) будем проверять абсолютно все функции, которые существовали до внедрения. С одной стороны, это здорово: так точно можно убедиться, что обновление не затронет вообще ничего лишнего и всё будет работать. С другой – для такого подхода нужно колоссальное количество времени и сил.

Как же сохранить пользу регресса, не скормив ему все ресурсы команды тестирования?

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

Мы пришли к выводу, что оптимальной для нашей ситуации будет динамически наполняемая регрессионная модель. Если точнее, то динамически наполняемый набор регрессионных кейсов для каждого конкретного релиза.

Вот как всё работает.

У нас есть набор тестовых сценариев по всей системе. Он пополняется буквально после каждого релиза, добавляются новые проверки, которые и составляют полную регрессионную модель. Из этой полной модели отбирается часть основных проверок, которые покрывают базовую функциональность системы. Если эти проверки по каким-то причинам не проходят, значит, где-то не работает базовая функциональность системы, и выпускать релиз нельзя. Состав этой базы каждая команда определила вместе со своим бизнес-заказчиком. Этот набор проверок обязателен и неукоснительно выполняется перед каждым релизом.

Оставшиеся кейсы мы разбиваем на модули, конкретные области функционала. В список финальных проверок перед релизом попадают только проверки тех модулей, которые могли быть затронуты добавляемыми фичами. «Круг подозреваемых» формируется как на основании экспертной оценки самой команды тестирования, аналитики и разработки, так и по информации от смежных команд. 

Кроме этого, мы проводим все автоматизированные проверки, так как их применение очень дёшево обходится с точки зрения трудозатрат. Проверить, отработали ли автотесты, довольно просто, это не доставляет каких-то проблем.

Обновления происходят раз в две недели – довольно распространённый релизный цикл. Чаще всего в релизы уходят бизнес-задачи, но иногда и просто небольшие фиксы, закрывающие техдолг или баги, о которых конечный пользователь мог и не догадываться. Внедрение бизнес-задач планируется заранее — бизнес передаёт свои пожелания и свежие идеи в IT, а IT-команды начинают работать с этими требованиями по стандартному циклу разработки ПО. Формируются технические требования, проходит разработка и полный цикл тестирования. Матричная операционная модель и командный подход позволяют делиться и реализовывать задачи бизнес-подразделения по полному циклу тестирования.

Планы на будущее

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

Риск применения неполного покрытия в том, что можно что-то упустить. Это не самая частая проблема, но всё же бывает. Хотя, как правило, при таком подходе до конечного пользователя доходят только минорные ошибки.

Но плюсы пока перевешивают: если сравнивать динамическую регрессионную модель со статической, то разница по трудозатратам ощутима. Например, в случае статической модели полное регрессионное тестирование могло бы занимать около 700+ человеко-часов. То есть команда из 15 человек сидит и больше недели только и делает, что занимается регрессионным тестированием. В таких условиях оперативно доставить какие-то полезные изменения до пользователя становится или слишком дорого и долго, или просто невозможно.