Привет. Меня зовут Ольга Михальчук, я QA-инженер (инженер по обеспечению качества или тестировщик) в финтех-компании ID Finance. В этом посте я расскажу вам, чем занимается QA и как найти и исправить ошибки в кредитных расчетах, прежде чем они приведут к большим убыткам в вашей компании.
Немного о моей работе: QA или тестировщик
ID Finance — финтех-компания с проектами в семи странах.Я работаю в Бразилии, продукт ДеньгиЧеловек (сервис онлайн-кредитования).
Для начала хотелось бы немного дать определение понятиям «инженер по обеспечению качества» и «тестировщик», хотя это тема для отдельной статьи.
Единого понимания этих понятий пока нет. В большинстве случаев тестировщики — это специалисты, проверяющие корректность работы системы после разработки и до предоставления функциональности конечным пользователям.
Под контролем качества мы подразумеваем более глобальную и углубленную работу по обеспечению качества продукции.
Сюда входит исследование причин дефектов, их предотвращение, обслуживание после выпуска, постоянное улучшение процессов и многое другое.
В реальности моя работа выглядит примерно так: мы анализируем и проверяем задачи, составленные другими отделами и разработанные программистами, вносим и разбираем ошибки, пишем тестовую документацию и отчеты, следим за состоянием производства, проводим демо и т. д. Мы также есть концепция производственного контроля качества.
Ребята из нашего отдела тоже должны иметь представление о процессе разработки: каждый день мы спускаемся на уровень баз данных и логирования системы, заглядываем в код и консоль, используем системы для мониторинга нагрузки и состояния системы.
Мы должны понимать специфику бизнеса: сюда входит анализ задач и общение с другими подразделениями.
Должен знать специфику работы других отделов.
Пример: как можно проверить, что начисления по кредиту проводятся правильно, если ты в этом не разбираешься? Именно поэтому в дальнейшем я буду называть свою должность QA, т. е.
специалист по обеспечению качества, хотя не обижусь, если меня назовут тестировщиком.
Тестирование расчетов по кредиту
В нашей компании под кредитными расчетами понимаются все расчеты параметров и показателей кредита.Это график платежей, размер основного долга и процентов, штраф в случае просрочки, расчет пошлин, налогов и т.д. Всего более 100 показателей в разных таблицах базы данных.
Помимо основных услуг, есть дополнительные: расширение, перестройка, ремонт. Также пользователю доступна система скидок, бонусов, различные кредитные продукты и масса других возможностей.
Кредитные расчеты — одна из самых сложных областей, с которыми я столкнулся за время работы в компании.
На мой взгляд, на таком же уровне сложности находится только кредитная политика (совокупность правил и алгоритмов, по которым принимается решение о возможности выдачи кредита и о том, какой кредит мы можем выдать данному пользователю).
Особенности тестирования кредитных расчетов
- Подготовьтесь к процессу тестирования заранее, в идеале — до разработки.
Анализ требований, подготовка тестовой документации.
- От более простых проверок переходим к более сложным и комбинированным: сначала проверяем выдачу кредита, своевременность погашения, сумму к сумме и т. д. Затем чуть более сложные проверки, такие как досрочное погашение, просроченное погашение, переплату, а затем сочетания разных случаев.
- Проверяем первоначальные настройки и договор, который подписывает заемщик.
- Не забывайте о дополнительных услугах (продление, скидки и т.д.)
- Производственная среда — это сокровищница тестовых примеров.
Неплохой идеей было бы взять «эталонные» случаи и сравнить с ними расчеты.
- Нельзя допускать, чтобы изменения в затратах влияли на существующих клиентов.
- Всегда следует помнить о регрессе после любых изменений.
- Мы учитываем, могут ли другие сторонние задачи повлиять на расчет кредита.
Конкретные кейсы: как ошибки могут отразиться на тысячах долларов дохода и как мы с ними боролись Я начал работать с расчетами, когда они уже были в релизе около двух лет, поэтому многих прелестей истоков этого процесса я не знал.
Тем не менее мне пришлось заняться их стабилизацией и исправлением ошибок.
Расскажу о случаях, которые мне запомнились больше всего: Ээффект бабочки в расчетах Если вы погуглите определение «эффекта бабочки», то увидите: «Эффект бабочки — это термин, обозначающий свойство некоторых хаотических систем: небольшое воздействие на систему может иметь большие и непредсказуемые последствия, в том числе и в совершенно другое место.
" Я думаю, что это определение прекрасно описывает ситуацию в кредитных расчетах.
Например, однажды мы исправили небольшую ошибку: была небольшая неточность округления некоторых полей.
После пересчёта всех кредитов (к счастью, на тестовой среде) выяснилось, что около тысячи кредитов просрочены, хотя на самом деле их быть не должно! Таков был эффект исправления той незначительной ошибки, поскольку в расчетах кредитов все параметры сильно переплетены и влияют друг на друга, иногда в неожиданных местах.
Слава Богу, это быстро заметили и исправили, не допустив попадания до конечных пользователей.
Дело в том, что информацию о просроченном платеже мы отправляем в кредитное бюро.
Мы могли испортить кредитные истории сотен клиентов и нашу репутацию.
И, конечно же, такая ошибка приведет к убыткам в тысячи долларов.
Невозможно исправить 100% ошибок
Как я писал в первом пункте, все параметры в расчетах сильно влияют друг на друга.
Из-за этого, чиня что-то в одном месте, очень часто что-то ломается в другом.
Когда перед нами стояла задача исправления большого количества накопившихся ошибок, конечно, бизнес-отдел хотел, чтобы были исправлены абсолютно все ошибки.
Но оказалось, что в попытках исправить какие-то неважные ошибки, как снежный ком, росли все новые и новые ошибки.
Как говорится, лучшее – враг хорошего.
Поэтому нашей главной задачей на тот момент было довести систему до максимально стабильного состояния, с минимальным влиянием ошибок на бизнес, а не исправлять 100% дефектов.
Такой подход оказался гораздо продуктивнее, чем бесконечное исправление все новых и новых ошибок, размножающихся друг от друга.
Внимание к нетривиальным сочетаниям
Большинство ошибок возникает именно при нетривиальных сочетаниях способов оплаты и использования кредита, когда ветки кода запутываются друг в друге.
Например: пользователь досрочно погашает первый взнос, оплачивает второй взнос в 5 этапов, оформляет пролонгацию на третьем, а потом уходит в задолженность на несколько недель.
К сожалению, зачастую ошибки в таких случаях уже есть производство.
Вывод: обратите внимание на комбинации кейсов и помните шестой пункт последнего раздела (производственная среда — кладезь тест-кейсов).
Мы не трогаем существующих клиентов! Любые изменения суммы, срока или условий кредита не должны влиять на существующих клиентов, которые взяли его на определенных условиях.
Если такой инцидент произойдет, это принесет массу неприятностей службе поддержки и всей компании.
Сравнение кредитных портфелей Очень эффективный метод проверить правильность работы расчетов по кредитам, если в них были внесены какие-либо изменения, – это сравнить кредитные портфели до и после изменений.
Это означает, что мы имеем относительно правильную кредитную базу, расчеты которой соответствуют ожиданиям бизнеса.
И мы применяем к этой базе данных новые расчеты по кредитам, а затем, используя специальные инструменты и анализ данных, сравниваем некоторые общие показатели этой кучи кредитов.
Например, количество просроченных кредитов до и после изменения или размер процентов по всем кредитам.
Этот метод очень полезен как при тестировании, так и при поиске проблем.
выводы
Кредитные расчеты – тема серьезная и сложная, но очень интересная и полная загадок.Работая с ним, нужно быть немного аналитиком данных, финансистом и математиком.
Но даже такого опасного зверя можно приручить, если найти к нему подход. А помогут в этом простые пункты:
- Тщательная подготовка: требования к качеству, бизнес-документация и QA-документация, продуманный дизайн тестов;
- Регрессия (помните про «эффект бабочки»);
- Производственная среда как незаменимый источник тестовых примеров и стандарта.
-
Наш Мозг Как Примитивная Нейронная Сеть
19 Oct, 24 -
Создание Гибких Анкет В Drupal 7
19 Oct, 24
