How to Stay Sane When Testing Insurance Products
Poltorakova Nina
Lead Testing Specialist
Hi, my name is Nina Poltorakova, I am a leading tester at Yuztech Group.
At the moment, my team and I are developing and supporting IT solutions in the Life direction – life insurance.
In this article, I want to share a few tips on how to avoid going crazy when testing insurance products.
Instead of an introduction
Over my more than 12 years in the field of testing and quality assurance, I have tested, managed, and visited completely different projects, from tiny commercial ones to huge and frightening government contracts. But somehow it historically turned out that I am drawn to insurance projects, and insurance projects are drawn to me.
Yes, my dear, you have an addendum.
The first thing that strikes you when you come to test insurance products is the abundance of insurance terms.
Addendums, ILI, cooling-off periods, semi-transactions, liability periods, CB structures, underwritings, brrr, we should sort out testing here first!
But it is impossible to test something whose meaning you do not understand, so in order not to go crazy, look for a dictionary of terms and abbreviations, the project definitely has one.
The tester's job is to test, not to know all the insurance terminology by heart.
If suddenly there is no dictionary on the project, start keeping your own and ask your teammates to fill it with you. So, in a few months you will already have a very impressive, and most importantly, useful document.
Users are our everything
There are legends in testing that if you know your user well, then life will turn out in the best possible way, luck will accompany you in all your endeavors, and bugs will literally appear in BTSki themselves. This is almost true.
In most projects, users are the very people on the other side of the screen, the end consumers of our product, always dissatisfied and wanting something, but when you test the internal software of an insurance company, the users will be somewhat different from the usual ones.
There is a nuance in insurance projects, here the users are the employees of the insurance company who work with our software every day: issue insurance, make payments. These are employees of operational management, accounting, insurance expertise.
Not only do these wonderful people know the whole process from the inside (and can tell you about it!), but they can also show you, the main thing is to have time to write it down.
To stay sane, communicate with users more often. Users are carriers of unique knowledge and expertise, do not neglect them, they will still be useful to you!
Therefore, if you have difficulties understanding what comes after what, in what sequence and what should be designed, feel free to ask to organize a meeting with users and ask for their help. Together with the project analyst, listen carefully to the user stories – the analyst will write a cool and unambiguous technical specification, and you will understand what functional blocks the story “passes” through, and what you will have to test.
Test the technical specifications
On our project, my team and I test the technical specifications with particular cruelty. Our fellow analysts jokingly call this process “roasting”.
And only when all errors have been eliminated (logic is broken, requirements are not atomic, ambiguous, there are syntactic and spelling errors in the specification, etc.) do we send it for development.
Why did we decide to test technical specifications? It is worth mentioning that literally a year ago there was no such process on the project, analysts after writing technical specifications gave them immediately for development, the process could be delayed due to a large number of questions, shortcomings and clarifications from the customer, which, in turn, made even a small revision quite expensive.
That is why the testing team brought up the issue of testing the technical specifications for discussion and received support from the entire product development team, because the technical specifications are probably one of the very first documents that everyone, from the tester to the IT director, will look at if any questions arise.
My colleague and I formulated the requirements for the requirements, introduced them to the entire team, and helped our analysts create “ideal” technical specification templates for the project.
The process of testing the technical specifications helps to understand what needs to be implemented, and therefore tested, and also helps to eliminate errors at an early stage of development and not let them into the product, as a result – leads to colossal savings of time, budgets and nerves.
To avoid going crazy, while testing requirements, throw in “fish” of future cases, and when the revision comes to you, correct, supplement and enrich them with test data, draw state and transition diagrams or build decision tables for visual clarity and easier understanding, because sometimes insurance requirements are so three-story that all that remains is to draw.
Document everything. That's all
As I said above, we write test cases. We write them for everything. And to keep from going crazy, we write them in great detail. Not because we love documenting, but because there is simply no other way.
Let me explain: we are testing legacy monoliths, let's call them “large information systems” or BIS for short. At first, there was one BIS, clumsy, inconvenient, slow, but it worked like a clock! It's worth saying a few words about what a BIS is in general, so that readers can imagine the scale of the “tragedy”: BIS is a powerful desktop application written in Delphi and “under the hood” having an Oracle database, a bunch of screen and product forms, any of which can be used to conduct usability podcasts for hours on end. Despite all this, the thing is reliable and, most importantly, it works!
However, we decided that the first BIS had served its purpose and it was time to replace it with something new, “clumsy” and convenient, and so the second BIS was born. We live like this to this day and we no longer make attempts to move somewhere or replace it with something, because we do not need a third BIS.
Preconditions, testing environment, role model if necessary, steps, results – we describe everything to the maximum, and even with pictures. Because in a week we ourselves will forget how, for example, to calculate the tax on the DIT on the contract or how to issue an addendum. We are not experts in the insurance business to remember this. And also, if they bring a newbie to us, do we tell him everything ourselves? God forbid, we will let him go through cases, let him get acquainted with the system in this way.
In addition to legacy monoliths, we also get tasks related to Rosfinmonitoring — this is a huge, scary, but very interesting and important area. In short, it is about not taking out insurance and not making insurance payments to a certain circle of people and organizations: terrorists and extremists, people who are banned from entering the Russian Federation, and so on. We receive such lists in different ways: via API, by mail, “by voice” from the relevant authorities or the CEO, we upload them to our databases and check the company's clients. Those who pass the check are carefully “marked” with green attributes in the client card, and from the “suspicious” ones we collect a report and send it by mail to the financial monitoring department. This is where everything should definitely be documented!
In order not to go crazy, clarify what lists, how and in what form you receive (these can be completely different data formats: csv, json, raw, xls, etc.), which of them are blocking (that is, people from these lists cannot be taken into insurance and make payments to them), and which are of a warning nature, how clients are marked depending on these lists, where the data is stored, whether matches with the lists are logged and how.
In addition to cases, try to document any information that is useful to you. For example, we even dedicated an entire page in Confluence to SQL queries to quickly select beneficiaries on a specific date, transactions under an insurance contract, or agency agreements.
Instead of a conclusion
Instead of a conclusion, I would like to highlight the main points that I talked about in the article. Testing insurance products is not an easy task, as is testing in general, but you can make life much easier for yourself and your colleagues by following simple recommendations:
Don't keep the meanings of insurance terms in your head, but use a dictionary;
Free up your RAM and write down everything that can help you in one way or another or come in handy during testing (cases, scripts, requests, instructions, etc.);
Test the technical specifications and at this stage get to know the functionality, sooner or later it will come to you for verification anyway;
Love communicating with users – they are the bearers of unique knowledge about your product and can tell you a lot of interesting things!
