Привет. Меня зовут Ольга Михальчук, я QA engineer (Quality Assurance engineer или тестировщик) в финтех-компании ID Finance. В этом посте я расскажу, чем занимаются QA и как искать и исправлять баги в кредитных калькуляциях, пока они не привели к большим убыткам в вашей компании.
Немного о моей работе: QA или тестировщик
ID Finance — финтех-компания, проекты которой представлены в семи странах. Я работаю на Бразилию, продукт MoneyMan (сервис онлайн-кредитования).
Для начала хотела бы немного определиться с терминами «Quality Assurance engineer» и «тестировщик», хотя это и тема для отдельной статьи. Пока нет единого представления об этих понятиях. В большинстве случаев тестировщиками называют специалистов, которые проверяют правильность работы системы после разработки и до предоставления функциональности конечным пользователям. А под QA подразумевают более глобальную и глубокую работу по обеспечению качества продукта. Сюда входит исследование причин возникших дефектов, их предотвращение, пострелизное обслуживание, постоянное усовершенствование процесса и многое другое.
В действительности моя работа выглядит приблизительно так: мы анализируем и проверяем задачи, которые составили другие отделы и разработали программисты, заносим и разбираем баги, пишем тестовую документацию и отчёты, мониторим состояние продакшена, проводим демо и т. д. Также у нас есть понятие Production QA. Ребята из нашего отдела должны иметь представление и о процессе разработки: мы ежедневно спускаемся на уровень баз данных и логирования системы, заглядываем в код и консоль, используем системы мониторинга нагрузки и состояния системы. Мы должны понимать специфику бизнеса: сюда входит и разбор задач и коммуникация с другими отделами. Должны знать особенности работы других департаментов. Пример: как можно протестировать, что начисления по кредиту проводятся правильно, когда ты в этом не разбираешься? Именно поэтому я в дальнейшем буду называть свою должность QA, т. е. специалист по обеспечению качества, хотя не обижусь, если меня назовут тестировщиком.
Тестирование кредитных калькуляций
У нас в компании кредитными калькуляциями называют все вычисления параметров и показателей кредита. Это график платежей, сумма основного долга и процентов, штраф в случае просрочки, начисление пошлин, налогов и т. д. В общей сложности более 100 показателей в разных таблицах базы данных. Кроме основных услуг существуют дополнительные: продление, реструктуризация, реновация. Еще есть система скидок, бонусов, разных кредитных продуктов, доступных пользователю и куча других особенностей.
Кредитные калькуляции – это одна из самых сложных областей, с которой я сталкивалась в течение работы в компании. На мой взгляд, на одном уровне по сложности находится только кредитная политика (набор правил и алгоритмов, по которым принимается решение о возможности выдать кредит, и какой именно кредит мы можем выдать данному пользователю).
Особенности тестирования кредитных калькуляций
- Подготовиться к процессу тестирования заранее, в идеале – до разработки. Проанализировать требования, подготовить тестовую документацию.
- Идём от более базовых проверок к более сложным и комбинированным: сначала проверяем выдачу кредита, погашений срок в срок, сумма в сумму и т. п. Потом чуть более сложные проверки, такие как досрочное погашение, просрочка, переплата, а затем комбинации разных кейсов.
- Проверяем начальные настройки и контракт, который подписывает заёмщик.
- Не забываем про дополнительные услуги (продление, скидки и т. д.)
- Продакшн среда – кладезь тест-кейсов. Хорошей идеей будет взять «эталонные» кейсы и сравнивать калькуляции с ними.
- Нельзя допустить влияние изменений в калькуляциях на существующих клиентов.
- Нужно всегда помнить про регрессию после любых изменений.
- Учитываем, могут ли повлиять на кредитные калькуляции другие сторонние задачи.
Конкретные кейсы: как баги могут повлиять на тысячи долларов выручки и как мы с ними боролись
Я приступила к работе с калькуляциями, когда они уже были в релизе около двух лет, поэтому я не знала многих прелестей зарождения этого процесса. Тем не менее мне пришлось столкнуться с их стабилизацией и фиксингом багов. Расскажу вам о случаях, которые мне наиболее запомнились:
Эффект бабочки в калькуляциях
Если загуглить определение «эффект бабочки», можно увидеть: «Эффект бабочки — термин, обозначающий свойство некоторых хаотичных систем: незначительное влияние на систему может иметь большие и непредсказуемые последствия, в том числе и совершенно в другом месте». Я думаю, это определение идеально описывает ситуацию в кредитных калькуляциях.
Как пример, однажды мы починили незначительный баг: была небольшая неточность в округлениях некоторых полей. После пересчета всех кредитов (благо на тестовой среде), оказалось, что около тысячи кредитов вышли в просрочку, хотя на самом деле не должны были! Так повлиял фикс того незначительного бага, ведь в кредитных калькуляциях все параметры сильно сплетены и влияют друг на друга, порой в неожиданных местах. Слава богу, это быстро заметили, починили, не допустив его попадания конечным пользователям. Дело в том, что информацию о просрочке мы отправляем в кредитное бюро. Мы могли испортить сотни кредитных историй клиентов и свою репутацию. И, конечно, такой баг вылился бы в тысячи долларов убытков.
Нельзя исправить 100% багов
Как я писала в первом пункте, все параметры в калькуляциях очень влияют друг на друга. Из-за этого во время исправления в одном месте очень часто что-то ломается в другом. Когда мы столкнулись с фиксингом большого количества скопившихся багов, конечно, бизнес-отдел хотел, чтобы были исправлены абсолютно все ошибки. Но получилось, что в попытке починить некоторые маловажные баги, вырастали всё новые и новые ошибки, как снежный ком. Как говорится, идеальное – враг хорошего. Поэтому нашей основной задачей на тот момент стало привести систему в максимально стабильное состояние, с минимальным влиянием багов на бизнес, а не исправить 100% дефектов. Такой подход оказался намного продуктивнее, чем бесконечное исправление всё новых и новых багов, плодящихся друг от друга.
Внимание нетривиальным комбинациям
Большинство багов возникает именно при нетривиальных комбинациях способов выплаты и использования кредита, когда ветвления в коде запутываются друг в друге. Например: пользователь погашает первый взнос заранее, второй оплачивает в 5 этапов, на третьем берёт продление, а потом уходит в просрочку на несколько недель… К сожалению, нередко баги в таких кейсах находятся уже на проде. Вывод: обращаем внимание на комбинации кейсов и помним про шестой пункт прошлого раздела (прод среда – кладезь тест-кейсов).
Не трогаем действующих клиентов!
Нельзя допустить, чтобы любые изменения суммы, срока или условий по кредиту затронули действующих клиентов, которые взяли его на определенных условиях. Если такой случай произойдет, это принесёт кучу неприятностей саппорт-отделу и всей компании.
Сравнение кредитных портфелей
Очень эффективный метод проверить, правильно ли работают кредитные калькуляции, если в них были внесены какие-либо изменения, — сравнить кредитные портфели до изменений и после. Это значит, что у нас есть условно правильная база кредитов, с калькуляциями, которые удовлетворяют ожиданиям бизнеса. И мы к этой базе применяем новые кредитные калькуляции, и потом с помощью специальных тулов и data-анализа сравниваем какие-то общие показатели этой кучи кредитов.Например, количество просроченных кредитов до и после изменений или сумму процентов по всем кредитам. Этот способ очень помогает как в тестировании, так и в поиске проблем.
Выводы
Кредитные калькуляции – хоть серьезная и сложная тема, но очень интересная и полная головоломок. При работе с ней надо быть немного и data-аналитиком, и финансистом, и математиком. Но даже такого опасного зверя можно приручить, если найти к нему подход.
А помогут в этом простые пункты:
- Тщательная подготовка: качественные требования, бизнес и QA документация, продуманный тест-дизайн;
- Регрессия (помним про «эффект бабочки»);
- Продакшн среда как незаменимый источник тест-кейсов и эталон.
Автор: IDFinance
