Home

Привет, меня зовут Нина Полторакова, я ведущий тестировщик в ГК Юзтех. 

На данный момент мы с командой занимаемся разработкой и поддержкой ИТ-решений по направлению Life — страхование жизни.

В этой статье я хочу поделиться несколькими приёмами, как не сойти с ума, тестируя страховые продукты. 

Вместо вступления

За свои более чем 12 лет в сфере тестирования и обеспечения качества я успела и потестировать, и поруководить, и побывать совершенно на разных проектах, начиная с крохотных коммерческих, заканчивая огромными и пугающими госконтрактами. Но как-то исторически сложилось, что меня тянет на страховые проекты, а страховые проекты тянет ко мне.

Да у вас, голубчик, аддендум

Первое, что поражает, когда ты приходишь тестировать страховые продукты — это обилие страховых терминов. 

Аддендумы, ИСЖ, периоды охлаждения, полупроводки, периоды ответственности, КВ структуры, андеррайтинги, бррр, тут бы с тестированием разобраться сначала! 

Но невозможно протестировать то, значение чего ты не понимаешь, поэтому, чтобы не сойти с ума — ищите словарь терминов и сокращений, он на проекте точно есть. 

Задача тестировщика — тестировать, а не знать назубок всю страховую терминологию. 

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

Пользователи — наше всё 

В тестировании ходят легенды, что если хорошо знать своего пользователя, то жизнь сложится наилучшим образом, удача будет сопутствовать во всех начинаниях,  а баги буквально сами будут заводиться в БТСки. Это практически правда. 

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

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

Эти прекрасные люди мало того, что весь процесс знают изнутри (и могут об этом рассказать!), так они ещё и показать могут, главное, успевайте записывать.

Чтобы не сойти с ума, чаще общайтесь с пользователями. Пользователи — носители уникальных знаний и экспертизы, не пренебрегайте ими, они вам ещё пригодятся!

Поэтому, если у вас возникли сложности с пониманием, что за чем идет, в какой последовательности и что должно оформляться, смело просите организовать вам встречу с пользователями, и просите их помощи. Вместе с аналитиком проекта внимательно слушайте истории пользователей — аналитик напишет классное и однозначное ТЗ,  а вы будете понимать, сквозь какие функциональные блоки «проходит» история, и что вам предстоит тестировать. 

Тестируйте ТЗ

На нашем проекте мы с командой тестируем ТЗ с особой жестокостью. Наши коллеги-аналитики в шутку называют этот процесс «прожаркой».

И только тогда, когда устранены все ошибки (нарушена логика, требования не атомарны, неоднозначны, в ТЗ имеются синтаксические и орфографические ошибки и так далее) отдаем в разработку. 

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

Именно поэтому команда тестирования вынесла на обсуждение вопрос о тестировании ТЗ и получила поддержку всей команды разработки продукта, ведь ТЗ — это, пожалуй, один из самых первых документов, куда заглянут все, от тестировщика до ИТ-директора, при возникновении каких-либо вопросов. 

Мы с коллегой сформировали требования к требованиям, познакомили с ними всю команду и помогли нашим аналитикам сделать «идеальные» для проекта шаблоны ТЗ.

Процесс тестирования ТЗ помогает разобраться в том, что подлежит реализации, а значит, и тестированию, а ещё — помогает устранить ошибки на раннем этапе разработки и не пустить их в продукт, как следствие — ведёт к колоссальной экономии времени, бюджетов и нервов. 

Чтобы не сойти с ума, во время тестирования требований накидывайте «рыбы» будущих кейсов, а когда доработка придет к вам — корректируйте, дополняйте и  обогащайте их тестовыми данными, рисуйте диаграммы состояний и переходов или стройте таблицы решений для визуальной наглядности и упрощения понимания, потому что порой страховые требования настолько трёхэтажные, что только рисовать и остаётся.

Докуменируй всё. Совсем всё

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

Объясню: мы тестируем legacy-монолиты, назовём их «большими информационными системами» или коротко — БИСы. Сначала был один БИС, неуклюжий, неудобный, медленный, но работающий как часы! Пару слов стоит сказать о том, что из себя вообще представляет БИС, чтобы читатели могли себе представить масштабы «трагедии»: БИС — это десктопное мощное приложение, написанное на Delphi и «под капотом» имеющее оракловую базу данных, кучу экранных и продуктовых форм, по любой из которых можно юзабилити-подкасты вести часами напролёт. Несмотря на всё это, штука надёжная и, главное, рабочая!

Однако, решили, что первый БИС отслужил своё и пора бы его заменить на что-то новое,«уклюжее» и удобное, так родился второй БИС. Так и живем по сей день и попыток куда-то переехать и на что-то заменить больше не предпринимаем, ибо третьего БИСа нам не надо. 

Предусловия, среда тестирования, ролевая модель при необходимости, шаги, результаты — всё описывается нами на максималках, да ещё и с картинками. Потому что через неделю мы сами же и забудем, как, например, посчитать налог с ДИДа на договоре или как выпустить аддендум. Мы ведь не специалисты в страховом деле, чтобы это помнить. А ещё, если к нам новичка приведут, самим ему всё рассказывать? Боже упаси, дадим ему кейсы проходить, пусть знакомится с системой таким образом.

Кроме legacy-монолитов к нам в работу попадают задачи по Росфинмониторингу — это огромное, страшное, но очень интересное и важное направление. Если коротко, оно про то, чтобы не брать на страхование и не делать страховые выплаты определенному кругу лиц и организаций: террористам и экстремистам, лицам, которым запрещён въезд в РФ, и так далее. Мы получаем такие списки разными способами: по API, по почте, «голосом» от надлежащих органов или генерального директора, загружаем в свои базы и проверяем клиентов компании. Прошедших проверку заботливо «маркируем» зелеными атрибутами в карточке клиента, а из «подозрительных» собираем отчёт и отправляем на почту в отдел финансового мониторинга. Вот уж где точно надо документировать всё! 

Чтобы не сойти с ума, уточните, какие списки, как и в каком виде вы получаете (это могут быть совершенно разные форматы данных: csv, json, raw, xls и др.), какие из них являются блокирующими (то есть лиц из этих списков нельзя брать на страхование и делать им выплаты), а какие носят предупредительный характер, как маркируются клиенты в зависимости от этих списков, где хранятся данные, логируются ли совпадения со списками и как.

Кроме кейсов старайтесь  документировать любую полезную вам информацию. Мы, например, даже выделили целую страницу в Confluence под SQL-запросы, чтобы быстро отобрать выгодоприобретателей на определенную дату, проводки по договору страхования или агентские договоры.

Вместо заключения

Вместо заключения хочу отметить основные моменты, о которых говорила в статье. Тестирование страховых продуктов — дело непростое, как и тестирование в принципе, но можно многократно упростить жизнь себе и своим коллегам, соблюдая простые рекомендации:

• Не держите в голове значения страховых терминов, а пользуйтесь словарем;

• Освободите свою оперативную память и записывайте всё, что так или иначе может вам помочь или пригодиться при тестировании (кейсы, скрипты, запросы, инструкции и пр.);

• Тестируйте ТЗ и уже на этом этапе знакомьтесь с функционалом, он рано или поздно всё-равно придёт к вам на проверку;

• Полюбите общение с пользователями — они носители уникальных знаний о вашем продукте и могут рассказать много интересного!