Особенности тестирования кредитов: как один баг влияет на тысячи долларов выручки

    Привет. Меня зовут Ольга Михальчук, я QA engineer (Quality Assurance engineer или тестировщик) в финтех-компании ID Finance. В этом посте я расскажу, чем занимаются QA и как искать и исправлять баги в кредитных калькуляциях, пока они не привели к большим убыткам в вашей компании.

    image

    Немного о моей работе: QA или тестировщик


    ID Finance — финтех-компания, проекты которой представлены в семи странах. Я работаю на Бразилию, продукт MoneyMan (сервис онлайн-кредитования).

    Для начала хотела бы немного определиться с терминами «Quality Assurance engineer» и «тестировщик», хотя это и тема для отдельной статьи. Пока нет единого представления об этих понятиях. В большинстве случаев тестировщиками называют специалистов, которые проверяют правильность работы системы после разработки и до предоставления функциональности конечным пользователям. А под QA подразумевают более глобальную и глубокую работу по обеспечению качества продукта. Сюда входит исследование причин возникших дефектов, их предотвращение, пострелизное обслуживание, постоянное усовершенствование процесса и многое другое.

    В действительности моя работа выглядит приблизительно так: мы анализируем и проверяем задачи, которые составили другие отделы и разработали программисты, заносим и разбираем баги, пишем тестовую документацию и отчёты, мониторим состояние продакшена, проводим демо и т. д. Также у нас есть понятие Production QA. Ребята из нашего отдела должны иметь представление и о процессе разработки: мы ежедневно спускаемся на уровень баз данных и логирования системы, заглядываем в код и консоль, используем системы мониторинга нагрузки и состояния системы. Мы должны понимать специфику бизнеса: сюда входит и разбор задач и коммуникация с другими отделами. Должны знать особенности работы других департаментов. Пример: как можно протестировать, что начисления по кредиту проводятся правильно, когда ты в этом не разбираешься? Именно поэтому я в дальнейшем буду называть свою должность QA, т. е. специалист по обеспечению качества, хотя не обижусь, если меня назовут тестировщиком.

    image

    Тестирование кредитных калькуляций


    У нас в компании кредитными калькуляциями называют все вычисления параметров и показателей кредита. Это график платежей, сумма основного долга и процентов, штраф в случае просрочки, начисление пошлин, налогов и т. д. В общей сложности более 100 показателей в разных таблицах базы данных. Кроме основных услуг существуют дополнительные: продление, реструктуризация, реновация. Еще есть система скидок, бонусов, разных кредитных продуктов, доступных пользователю и куча других особенностей.

    image

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

    Особенности тестирования кредитных калькуляций


    1. Подготовиться к процессу тестирования заранее, в идеале – до разработки. Проанализировать требования, подготовить тестовую документацию.
    2. Идём от более базовых проверок к более сложным и комбинированным: сначала проверяем выдачу кредита, погашений срок в срок, сумма в сумму и т. п. Потом чуть более сложные проверки, такие как досрочное погашение, просрочка, переплата, а затем комбинации разных кейсов.
    3. Проверяем начальные настройки и контракт, который подписывает заёмщик.
    4. Не забываем про дополнительные услуги (продление, скидки и т. д.)
    5. Продакшн среда – кладезь тест-кейсов. Хорошей идеей будет взять «эталонные» кейсы и сравнивать калькуляции с ними.
    6. Нельзя допустить влияние изменений в калькуляциях на существующих клиентов.
    7. Нужно всегда помнить про регрессию после любых изменений.
    8. Учитываем, могут ли повлиять на кредитные калькуляции другие сторонние задачи.

    image

    Конкретные кейсы: как баги могут повлиять на тысячи долларов выручки и как мы с ними боролись

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

    Эффект бабочки в калькуляциях

    Если загуглить определение «эффект бабочки», можно увидеть: «Эффект бабочки — термин, обозначающий свойство некоторых хаотичных систем: незначительное влияние на систему может иметь большие и непредсказуемые последствия, в том числе и совершенно в другом месте». Я думаю, это определение идеально описывает ситуацию в кредитных калькуляциях.
    Как пример, однажды мы починили незначительный баг: была небольшая неточность в округлениях некоторых полей. После пересчета всех кредитов (благо на тестовой среде), оказалось, что около тысячи кредитов вышли в просрочку, хотя на самом деле не должны были! Так повлиял фикс того незначительного бага, ведь в кредитных калькуляциях все параметры сильно сплетены и влияют друг на друга, порой в неожиданных местах. Слава богу, это быстро заметили, починили, не допустив его попадания конечным пользователям. Дело в том, что информацию о просрочке мы отправляем в кредитное бюро. Мы могли испортить сотни кредитных историй клиентов и свою репутацию. И, конечно, такой баг вылился бы в тысячи долларов убытков.

    image

    Нельзя исправить 100% багов

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

    image

    Внимание нетривиальным комбинациям

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

    Не трогаем действующих клиентов!

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

    Сравнение кредитных портфелей

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

    image

    Выводы


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

    А помогут в этом простые пункты:

    • Тщательная подготовка: качественные требования, бизнес и QA документация, продуманный тест-дизайн;
    • Регрессия (помним про «эффект бабочки»);
    • Продакшн среда как незаменимый источник тест-кейсов и эталон.
    ID Finance
    Международная финтех-группа ID Finance

    Comments 14

      0
      Интересно, спасибо. Как ваш коллега хотел посмотреть в LinkedIn, но к сожелению не нашел ваш профиль. Не могли бы вы указать ваш профессиональный опыт в годах? Просто чтоб проверить мою догадку?
        0
        Добрый вечер. Мой опыт как QA 2.2 года, в IDFinance работаю с марта 2018.
        Изложенное в статье является по большей части моими собственными суждениями, и конечно я не претендую на их неоспоримую правильность и буду рада узнать ваше мнение:)
          0
          До этого ещё год занималась чистым тестированием без процессов QA.
        –7
        Фу таким быть. Подсчитывать выгоду ростовщиков и хвастаться этим. Это всё равно что в РКН работать и с упоением рассказывать, как придумывать новые способы блокировки. Законы же.
          +1
          так вроде кредиты никто брать не заставляет
            0
            Ростовщик? Где ростовщик? Жирновато, не надо так.
            Безотносительно того этично ли работать на ростовщиков — из текста ТС следует что он работает на кредиторов, а не ростовщиков. Не стоит огульно навешивать плохой ярлык на человека, даже если причина этому просто незнание Вами терминологии.
            Поскольку способ наезда и (невольная?) ошибка часто повторяемы, позволим себе разьяснить.
            оффтоп
            Ростовщик подмножество кредитора. Не каждый кредитор ростовщик, но каждый ростовщик кредитор.
            Кредитор выдает кредит с целью получить прибыль от выдачи кредита. В этом ничего страшного, тот же самый пресловутый «беспроцентный исламский банкинг» куда страшнее с некоторых точек зрения.
            Ростовщик выдает кредит который заемщик заведомо не сможет вернуть, знает об этом и рассчитывает на прибыль именно в результате невозврата.
            Разница между ростовщиком и кредитором примерно такая же как разница между рейдерским захватом и покупкой акций компании. Или такая же как между черным хакером и исследователем уязвимостей.

              –7
              Вы давно в интернете? Тут принято высказывать своё мнение.
              Я не называл человека ростовщиком. Я указал на то, что он (она) работает на них. Ваш комментарий подтверждает, что в числе прочего на них то же. С чем вы не согласны? Простите, не уточнил. Я высказал своё мнение по отношению ко всем кредитным организациям, не только к ростовщическим, которые как правило таковыми себя не считают.
              Получить кредит нынче — как в туалет сходить. А вот выплатить и закрыть все эти кредиты — тут надо проявлять верх героизма для большинства не всегда финансово достаточно грамотных граждан. И я не поддерживаю нынешнюю кредитную систему и политику. Работа по оценке — поддержка, и даже пособничество в этой коварной яме.
              Надеюсь, раскрыл своё мнение, «корма» не оставил.
                +1
                Так дойдем до критики извлечения прибыли и добавленной стоимости в целом. Спасибо, уже проходили это, кажется, в 1917-1991 годах.
                0
                Сорри за некропостинг, но стало очень любопытно: чем так страшны шариат-финансы?
              +4
              Статья оставляет послевкусие школьного сочинения крепкого «хорошиста» на тему тестирования ПО. Такое ощущение возникает как от заголовка в духе Дейла Карнеги, так и от выводов, подходящих под любую «куашную» задачу.
                0
                Собственно говоря поэтому я и спрашивал про опыт. Чувствуется что автор еще немного не обстрелян в суровой действительности приоритетов, дедлайнов и прочих атрибутов с которыми надо счтитатьсяю Ну и не хватает кусочка про автоматизацию.
                  0
                  Думаю, я понимаю, что Вы имеете в виду. Действительно, в реальности не всегда есть возможность действовать по best practices тестирования.
                  Но дело в том, что у нас в компании понимают важность регрессии, тест-дизайна и других куашных активностей, когда дело касается кредитных калькуляций. Поэтому возможность провести полноценное тестирование нам дают. Конечно, бизнесу это понимание пришло не сразу, были и факапы, и обсуждения, и много чего другого :)
                  Про автоматизацию стоило упомянуть, согласна, спасибо. Она действительно в той или иной степени у нас применяется.
                0
                Очень занятно. А набор DQM-индикаторов используете при тестировании?
                  0
                  Добрый день!
                  Мы в нашем отделе тестирования не оперируем термином data quality monitoring индикаторы, но, если я правильно понимаю смысл, который Вы вкладываете в это понятие, мы используем его подходы.
                  Например, мы контролируем и мониторим качество данных так:
                  — соответствие данных бизнес-требованиям (полнота, правильный формат, сроки хранения и актуальности),
                  — нефункциональным требованиям (отсутствие дублирования, модификации при обработке, возможность восстановить данные и т д);
                  — мониторим, какие данные приходят от сторонних сервисов (не шлют ли ошибки, или не поменялся ли формат API и т д);
                  — Production QA (должность переходит от спринта к спринту разным людям, в том чмсле мне) кверит БД, пользуется системой мониторинга базы (может Вы это имели в виду?). Она называется Zabbix, с заданной периодичностью выполняет запросы в БД, и там указано, какой ответ является нормой, а какой нет. Если проблема — шлёт нотификацию.

                Only users with full accounts can post comments. Log in, please.