Привет! Я Андрей Непряхин, руководитель направления QA в AGIMA. Вот уже год как мы работаем над мобильным приложением платформы Финуслуги, созданной Московской биржей. Это первая и единственная платформа личных финансов в России. За этот год мы освоили целый ряд новых технологий, поняли, как обеспечивать качество крупного финтех-проекта, но главное — научились работать в огромной команде. Как мы сделали процесс тестирования измеримым, а взаимодействие с разработчиками прозрачным — расскажу в этой статье.

Немного о проекте

Финуслуги — это платформа личных финансов с помощью которой можно выбирать и открывать банковские вклады онлайн в режиме 24/7, брать кредиты наличными, приобретать полисы ОСАГО, ипотечного страхования, а также народные облигации российских регионов. Финуслуги созданы Московской биржей в рамках проекта «Маркетплейс» Банка России. В 2020 года Финуслуги выпустили веб-версию, а через год решили сделать мобильное приложение и пригласили команду AGIMA к участию в разработке.

Перед нами поставили цель — создать мобильное приложение с нуля в сжатые сроки. Поэтому было важно наладить четкий процесс. Наши специалисты участвовали во всех этапах разработки: от архитектуры и дизайна до поддержки. Об этом можно подробно прочитать тут и тут. А я расскажу только о той части разработки, которая касалась меня — об обеспечении качества продукта.

Особенности команды

На первых порах наша команда состояла из трех человек: QA Lead и еще два тестировщика. Нашей первостепенной задачей было выстроить прозрачный и измеримый процесс тестирования для своевременного получения информации о состоянии разрабатываемого продукта и оценки его качества.

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

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

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

Процессы на проекте 

Первым делом, начиная проект, мы разработали план тестирования. Весь процесс описали с учетом специфики крупных финтех-приложений: микросервисов, множественных интеграций. Четко обозначили скоуп тестирования и зоны ответственности, чтобы каждое заинтересованное лицо понимало, чем и в какой момент времени занимается тестировщик. Системой управления тестированием сначала был TestRail, затем решили перейти на TestOps. Все результаты тестирования отображались там.

Тестирование внутри 2-недельного спринта было поделено на несколько этапов:

1. Тестирование фич — сначала 5 дней, потом увеличили до 6. За это время мы должны были протестировать все фичи, разработанные за спринт, а также актуализировать регрессионную модель.

2. Стабилизация сборки — 2 дня. На этом этапе мы не принимали новые фичи на тестирование. Те из них, которые не попали к нам в первые 5–6 дней, выносились в следующий спринт. На этом этапе мы занимались регрессионным тестированием, которое изначально было ручным.

3. Смоук на препроде — 1 день. Протестированные фичи мы деплоили на препрод и проводили смоук-тестирование.

4. Проверка на проде — 0,5 дня. На этом этапе мы проводили последние проверки и выкатывали сборку для бета-тестирования на прод. Через некоторое время фичи выпускались для всех пользователей в маркеты.

Жизненно важной задачей было установить общий флоу на всем проекте — вне зависимости от количества команд разработки. Сложность состояла в том, что другие команды тоже разрабатывали микросервисы и всем системам нужно было взаимодействовать друг с другом, а нам проверять это взаимодействие. Если соседняя система нам отдавала сырой API, мы могли не заметить этого, так как не знали какие задачи релизят смежные команды.

Благодаря единому флоу каждый знал, какие фичи выпустит соседняя команда в следующий релиз. Это дало возможность прогнозировать, как и на кого повлияет наша фича. Мы могли прийти к соседней команде и сказать: «У нас в работе такая-то фича, она на вас может повлиять. Заложите в регрессионное тестирование проверку корзины и функциональности полисов ОСАГО у себя на вебе». Так все команды приложения могли понять, кто их может заафектить.

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

Если говорить про флоу тестирования, то он был базовым. Мы планировали спринт, делали оценку, причем оценивали задачи в сторипоинтах — не в часах, а по сложности задач. Для этого был выявлен эталон задачи, который имел сложность в 3 сторипоинта, и мы от него отталкивались в большую или меньшую сторону. Тестировщики приступали к разработке тест-кейсов, как только начинался спринт, параллельно с разработкой фич. Прежде чем задача переводится в тестирование, она должна соответствовать следующим критериям, которые заполняются разработчикам:

• задача разработана,

• задача внесена в релиз-ноутсы,

• нету замечания к требованиям по задаче.

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

• разработаны тест-кейсы,

• задача протестирована,

• тестовая модель актуализирована.

Дальше задача переводится на бизнес-приемку.

Спектр задач

Мы занимались тестированием всех уровней приложения: Backend, BFF и Frontend. Также мы учитывали особенности мобильного тестирования. Существует много девайсов, и на каждом приложение будет работать по-своему. Это и платформы iOS и Android, и версии систем. Например, на iOS 14.0 приложение может работать корректно, а на iOS 14.01 появляются баги вёрстки. Всё это нужно учитывать.

Более того, важно было учитывать и внешние обстоятельства. Что будет, если пользователь зайдет в метро? Как приложение будет вести себя, когда нет связи? Будет ли оно работать или крашнется? Мы это всё проработали. Каждый раз на регрессионном тестировании меняли набор проверок. Конечно, до того момента пока не были разработаны автотесты.

Тестировщиков привлекали на всех этапах разработки: мы валидировали требования бизнеса, ТЗ аналитиков, оценивали задачи, выделяли Acceptance-критерии для приемки, разрабатывали тест-кейсы и тестировали фичи. Каждую ошибку мы раскладывали по полочкам: искали ее причины, проводили ретро, где разбирали наиболее противные и сложные баги, особенно с прода. 

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

Технологии

Мы много работали с Kibana и Kubernetes. Научили команду перезагружать микросервисы, понимать, когда микросервис отваливается и к кому идти в этой ситуации. Мы научились смотреть и понимать логи всех команд. Тестировщики на «Финуслугах» фундаментально разбирались в причине ошибки, а не просто ее заводили. Так мы экономили время разработчиков.

Микросервисы — это во многом зависимость разных API между собой. В разработке у разных команд были разные API. Поэтому наше API могло обгонять API соседей. Или, например, фронт иногда мог обгонять бэк: API еще не готов, а мы готовы тестировать. На этот случай мы сами начали разрабатывать моки (mocks). Обычно этим занимаются разработчики, но мы решили снять с них эту активность и выбрали сервис WireMock. Он позволил нам самим писать моки на JSON, осталось лишь обучить инструменту тестировщиков.

Дефекты у нас хранились в Jira. Тестировщики работали с базами данных PostgreSQL, проверяли данные на соответствие типам и их атрибутному составу.  Также работали с очередями в Kafka и с крашлитикой Firebase. Testflight и Firebase мы использовали, чтобы тестировать прод и тест сборки. Трафик ловили через Charles.

Еще тестировщики работали с Amplitude. Там мы тестировали работоспособность метрик продуктовой аналитики: записывает ли система события, корректные ли данные приходят. Активно пользовались самописным инструментом для сбора метрик из Jira. Метрики — отдельная тема для разговора, они заслуживают отдельной статьи. Здесь я лишь напишу, что мы очень жестко их контролировали и старались не допускать отклонения от целевых показателей, в случае отклонений происходила точечная работа с командой. 

Автотесты

Начиная проект, мы понимали предстоящий объем работ и сразу было очевидно что после выпуска MVP нам нужно будет разрабатывать автотесты. Объем работ был запланирован большой. Мы тестировали мобильное приложение, но в смежных командах уже давно и активно шла разработка веб-версии, для которой уже был разработан фреймворк автоматизации и написаны автотесты. Так как API у всех общее, то мы решили переиспользовать фреймворк для API тестов. Познакомили с фреймворком ручных тестировщиков и отправили автоматизировать наше API. Конечно же, под контролем лидов-автоматизаторов.

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

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

Важная деталь: мы установили своего рода кволити-гейты, ворота качества для сборок. Мы не могли вылить новую сборку на следующую площадку, пока она не будет удовлетворять ряду критериев:

1. Все задачи в сборке должны пройти код-ревью.

2. Все задачи должны пройти через статический анализатор кода.

3. Сборка должна пройти через наши автотесты.

Только при условии 95% успешно пройденных автотестов, у нас происходит деплой на тестовую площадку. Если автотест падает, это значит, что надо срочно идти и разбираться. 

Что в итоге

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

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

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

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