Insurance companies have found themselves with a surplus of funds after the pandemic. Here's why it should go towards testing.
Insurance companies leverage a variety of applications and processes to run their business (both frontend and backend), from new policy creation all the way through to claims underwriting. A traditional approach, or should I say misunderstanding of a traditional approach, would be to aim for 80% test coverage and automate everything. This brings some challenges. For one, automating everything and gaining 80% test coverage is often simply not possible. Nor is it wise, and it can result in testers wading darkly through the quagmire of interrelated end-to-end systems and processes emphasizing testing and test coverage above QA's first principle: to assure the quality of the app, not the tests. But with all this end-to-end complexity, how does one begin to know what to test, what to automate, and when to do it? Well, let’s dig a little deeper and take a look.
Let’s kick off with when is it time to automate. In fact, let’s make this a little broader. Let’s look at when it’s time to look at your automation strategy. And the answer is now. As the Guardian reported, many insurers have seen increased profits from reduced claims during the pandemic. This applies to many disparate types of insurance from medical to automotive. But the good times will not last forever, and companies will need to think how to reinvest in this famously competitive industry. Those who modernize their testing will be in the best position moving forward. So how do you go about revisiting your test automation strategy?
As with most unwieldy testing challenges, the first thing to do is take a step back, look at what you need to test, and put things into buckets. That is to say, meaningfully categorize what you need to test. A typical result of such a process would give you something like the following five buckets:
This list is an example and may or may not be exhaustive depending on your organization's testing challenges. Each of these buckets has its own challenges and bugs in any of them present inherent business risks which must be understood. Ranking individual test cases within each bucket will need to happen. That said, we are able to prioritize each of these buckets.
One important area to consider is how often each of these buckets is likely to change. Application change represents the most likely area for bugs and regressions to enter the system and where most testing efforts should be made. For example, in the competitive and ever-changing landscape that is insurance, new business applications and processes are most likely to change. In comparison, claims management systems are far more static. As a starting point, you will want to give greater priority to those systems more likely to change.
Furthermore, when you consider the cost of acquiring customers in insurance is generally 7-9 times greater than selling to an existing customer, you see how individual test cases in the new business bucket are business-critical. Of course it is not that simple - you may have a few business-critical processes in any of the other buckets. Ensuring that policies are in place and will be indemnified are pretty critical. However, this is a great start and shows where the majority of your recourses should be focused. Furthermore, 80% test coverage in your claims bucket is probably overkill and may constitute a significant amount of test redundancy.
With the above said, you should then start to list your test cases for each bucket in order of how critical they are to your business (this way you will test and automate with an understanding of risk). These should generally be the tests you give priority to automating. When adopting this approach, you get more bang for your buck. As opposed to aiming for blanket coverage, you have identified where change is most likely to happen and cause regressions and the areas that are most business-critical. Meaning you can move faster while offering more assurance. There are other factors to consider: automating a manual test that takes seconds to execute may not be the most efficient use of resources. It is not the purpose of this blog to go into that, and there is a whole host of literature on the internet explaining just that.
Having prioritized and incorporated risk into your testing strategy, you will want to select some end-to-end user journeys to assure quality across all your interconnected systems. This has generally been seen as difficult and time-consuming to do. The good news is that modern tools such as Virtuoso have made in-sprint, end-to-end test automation a reality. You can now test individual systems based on their likelihood to change and their inherent risk and still have time to test entire journeys from your customers' perspective. To find out more, please book a demo. And if you want to dig even further into the details, subscribe to our blog. Next week, we will look at insurance testing in much more detail.
