Тестирование сервисов страховой компании

Крупная страховая компания с собственной цифровой экосистемой.

У страховой компании в разработке было несколько важных внутренних сервисов:

1. Обработка платежей. Система принимает платеж от клиента, проверяет его валидность и распределяет по разным получателям (например, часть — клиенту, часть — партнеру).
2. Расторжение договоров. Агент оформляет заявление, система проверяет документы, рассчитывает сумму возврата и вознаграждения, а затем передает данные дальше по процессу.

Ошибки в таких сервисах напрямую влияют на деньги и на клиентский опыт. Поэтому ключевая задача — обеспечить стабильность работы внутренних модулей.

Наш QA-специалист был ответственным за тестирование в двух проектах:

1. Оркестратор платежей

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

Как тестировалось:

1. Проверка API-запросов. QA отправлял платеж в систему через API. Сервис должен был принять запрос и переслать данные в брокер сообщений Kafka. Там у каждого типа сообщений есть свой «ящик» — топик. Проверялось, что сообщение попало именно в нужный топик.

2. Проверка базы данных. После того как сервис обрабатывал сообщение, в базе данных должна была появиться новая запись. QA сравнивал данные в базе с исходным платежом и убеждался, что они совпадают.

3. Проверка фоновых процессов. В системе были «джобы» — автоматические задачи, которые запускались по расписанию. Чтобы проверить их работу, QA вручную добавлял тестовые сообщения в Kafka и смотрел, правильно ли джоба их обрабатывает и записывает в базу.

4. Защита от дублей. Если одно и то же сообщение случайно отправить повторно, система не должна была создать вторую копию записи. Для этого моделировались ситуации с дублирующимися сообщениями.

5. Отладка и диагностика. Все действия проверялись по логам и через мониторинг в Grafana — там отображались ошибки и статус работы сервисов.

Особенность: наш тестировщик был единственным QA на этом направлении. Он отвечал за весь цикл: от написания чек-листов и подготовки тест-кейсов (в том числе адаптированных под автоматизацию), до демо, где показывалась полностью протестированная реализация и принималось решение о релизе.

2. Платформа терминации

Тестирование здесь включало и интерфейс для страховых агентов, и всю сложную «начинку» на бэке.

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

• Проверка расчетов. После того как агент оформляет заявление, система автоматически считает сумму возврата клиенту и вознаграждение агенту. QA сравнивал эти расчеты с ожидаемыми, тестировал пограничные сценарии: комиссии, частичный возврат, разные виды договоров.

• Передача данных дальше по процессу. Сервис не просто считал суммы, а передавал результаты в другие модули страховой компании. Проверялось, что данные уходят правильно, не теряются и не искажаются.

• Работа с документами. Важно было убедиться, что к заявлению можно прикрепить нужные документы, а система корректно проверяет их наличие.

В ходе тестирования был найден критичный баг — ошибка в расчетах, из-за которой целая фича (состоявшая из нескольких связанных задач, над которой команда работала довольно долго) оказывалась полностью нерабочей. Если бы её выложили в продакшен, вся работа пошла бы впустую. После находки требования переписали, а функционал реализовали заново.

Еще одна сложность: почти две недели QA был единственным тестировщиком на проекте, хотя объем работы был рассчитан на двоих. При этом он не только закрыл все задачи, но и помог в онбординге нового специалиста, быстро введя его в курс дела.