Материал основан на реальном проектном опыте.
Очевидно, каждая компания, вверяющая результаты своей деятельности программному продукту, в какой-то момент приходит к мысли: так ли безупречно работает алгоритм?
В самом деле: со временем вариативность вычислений возрастает, появляются новые параметры, операторы заводят множество данных, но правильные ли числа получаются на выходе? А ведь иногда речь идёт ещё и о расчёте выплат, то есть ошибка может приводить к реальным финансовым потерям. Как удостовериться в том, что потерь удастся избежать?
Не удивительно, что в одной крупной страховой компании однажды возник вопрос: безупречно ли функционирует их система расчёта КАСКО? За ответом на этот вопрос они обратились к нам. Была поставлена задача: протестировать систему расчёта стоимости страховки, сделав упор в первую очередь на корректность расчетов. Мы имели предоставленные компанией подробнейшие системы принятого расчёта, составлявшие около 30 итоговых коэффициентов для 39 регионов (именно таков был размах этой страховой) и 39 больших файлов.
Тест кейсы
Приступили к конструированию тестов. На первый взгляд, задача казалась типовой:
Шаг 1. Создать один базовый «тест по умолчанию» и внимательно проверить вручную.
Шаг 2. Перебрать все коэффициенты, создав набор тест-кейсов следующим образом: для каждого значения коэффициента создать один тест, где все значения взяты из «теста по умолчанию», кроме нашего проверяемого. Ожидаемый результат расчётов для такого теста легко получить, ведь менялся бы только один коэффициент за раз. Так же легко было по ошибочному тесту сразу вычислить то, в каком коэффициенте вкралась ошибка. Данный подход к созданию тестов носит название «атомарный».
Практически сразу пришло понимание того, что самый простой метод, как чаще всего и бывает, не самый эффективный. Эксперимент показал, что точное и аккуратное проведение одного теста занимало до 10-15 минут. Финальное влияние коэффициентов было видно только после заполнения всех данных. То есть на проверку одного региона нужно было потратить 14 человеко-дней, а на все регионы — 546. Мы же при согласованном бюджете могли выделить на данную работу только трех специалистов в течение 10 рабочих дней.
По мере ознакомления с вопросом проявились и другие сложности:
- Среди огромного количества параметров, влияющих на коэффициенты (одних только моделей автомобилей было указано более 700), некоторые были взаимосвязаны, а другие подключались только в отдельных случаях (например, только тогда, когда страхователь являлся юридическим лицом).
- Риск «Хищение» оценивался по комплектам противоугонных устройств, установленных на автомобиле (при этом функционирование каждого устройства описывалось целым рядом таблиц с данными). А требования к этим устройствам разнились от модели к модели.
- Коэффициентов было около тридцати, при перемножении (а точнее, при занесении их в таблицы Excel, где мы дублировали расчёты) возникала вероятность ошибки. И результат теста был визуально не очевиден.
- В ряде случаев обычное математическое округление приводило к неправильной оценке теста.
В условиях ограниченного по трудовым ресурсам задания мы приняли следующую стратегию тест-анализа:
- Поскольку от нас требовалась проверка только правильности расчетов, мы посчитали возможным выбрать для тестирования три региона – по количеству тестировщиков.
- Мы разбили на классы эквивалентности параметры, которые имели более 30 значений, а именно параметры «Машины» и «Противоугонные устройства». К примеру, параметр «Машины» мы разделили по марке, по стоимости и, конечно, отдельно выделили самые угоняемые, по которым нужно было дополнительно проверять класс противоугонных устройств.
- К параметрам «Возраст» и «Стаж» мы применили метод «Комбинирование связанных параметров», составив таблицы с комбинациями по позитивным тестам. Такие же таблицы были составлены и для других связанных параметров (например, для параметров «Юрлицо» и «Мультидрайв»).По клику на картинку откроется полная версия.
- Наш тест-кейс «по умолчанию» был подобран так, чтобы итоговые коэффициенты были максимально близки к единице. В итоге, при изменении только одного параметра, результат сразу превращался в коэффициент этого параметра. Что позволяло проводить тесты быстрее и оценивать результат точнее.
Результатом нашей работы стало создание системы из 82 тестов, которые можно было быстро провести для всех регионов. Наши тестировщики, проведя эти тесты для трех выбранных регионов, выявили 22 ошибки, причем 9 из них – именно в расчете итоговой суммы стоимости страховки! Например, оказалось, что в модуле «Договоры» при страховании по риску «Ущерб» при указанном чек-боксе «Автозапуск» (то есть в машине установлена сигнализация с функцией автозапуска) страховая премия рассчитывалась с неверным коэффициентом (а именно, как и «без автозапуска»).
При презентации результатов работы выяснилось, что к существованию таких багов в программе страховщики были не готовы и на демонстрации даже не верили нам, проверяя баги на рабочей версии программы! Предложенная нам задача была решена в полной мере, а мы приобрели ценный опыт по тестированию продуктов избыточной сложности в сжатые сроки.
