The time for insurance companies to change their test automation strategy is now.
As I noted in my previous blog on testing and the insurance industry, the pandemic has seen many different kinds of insurers receive fewer claims. This has resulted in larger profits. Many will be looking to reinvest this as we return to hyper-competitive normality in the industry. It is known that implementing a new or revisiting an existing test automation strategy is an area that offers a considerable return on investment. But not all test automation tools are built the same. With the multitude of solutions on offer, it can be hard to know which to choose. Let’s dig in and have a look at the pertinent points when choosing a tool in light of the insurance market’s specific conditions.
Make hay while the sun shines. It is certainly true that if you are currently over-reliant on manual testing, have a test automation estate that is nigh impossible to maintain, or are not performing any functional UI tests, the extra cash insurers have generated gives you the perfect opportunity to invest and gain a return. But what you also want to avoid at all costs is kicking the can down the road by either investing more heavily in what you have or selecting a tool not built for the digitally transformed world. Let’s have a look at an example:
For ease, let’s say you have a regression pack of 100 test cases automated using a framework such as Selenium (a fantastic set of tools with known drawbacks); maintenance is crippling you every time you run the pack. Multiple test engineers have built the framework over the years to the extent that you are not sure how much redundancy is in it. You could then invest heavily in the framework to remove that redundancy and get less brittle tests. You could even get your engineers to work with devs to build the app in a more testable way (that’s not always the easiest conversation given everyone’s competing priorities and the pressure there is on everyone in the SDLC to release quickly). You may start to see your maintenance overhead come down, and you can be sure that you’re testing the app, not just keeping redundant tests going. And I say “may,” as this is not an easy task, and this is only with a 100 test case regression pack. At this point, you may feel that you have fixed the problem, but it may be more that you have postponed the problem and just gifted it to future-you.
Maintenance is always going to be a problem with frameworks and indeed more modern approaches that use recorders. They produce flaky tests that are difficult to maintain. To get them to work, you rely on individual engineers. Good luck finding those. If you are looking to revisit your test automation strategy or transition from manual to automation, it is imperative that you pick a tool that has low maintenance overhead and has been specifically built for the pressures of the modern SDLC.
The insurance industry does not exist in a vacuum. While it may seem “like we never had it so good” (tongue firmly in the cheek on that one), we all know that there are increasing demands on wages. The tech talent war is making it increasingly difficult if not nigh impossible to recruit and keep highly-skilled engineers. When thinking afresh about your test automation strategy, you will need to factor in potential spiraling in costs. And more fundamentally, you will need to decide whether you are going to be able to find the right people to amend/create and maintain traditional forms of test automation. And when we consider that frameworks and recorders used in conjunction with code are so engineer-centric you have another problem for future you. Are you going to be in a position in three years' time of recruiting a software development engineering in test (SDET) that spends fixing flaky tests that another SDET wrote today?
Those working in the insurance industry no longer need to rely on tools that were designed nearly two decades ago. They can now leverage next-generation tools that heal themselves. Self-healing that works may appear a wild claim, but let’s see how it is done using Virtuoso.
Virtuoso collects xPaths (inherently unstable, IDs, other selectors, and other attributes) when identifying an object. Then Virtuoso uses this information on each run to decide if the element has changed. You no longer have to think about what you use to identify the element. We collect all the information for you and run an algorithm to determine if the element has changed or not. You also do not need that development knowledge of what is and is not likely to change. Your future engineers do not need to spend most of their time rummaging around code they have not written to find out why a test broke. Equally importantly, future-you is happy.
And the gains do not stop there. With Virtuoso, you can author with Natural Language Programming. Each test step is written in plain English and executed before your eyes at the same time. If you can write a manual test script, you can automate tests. What’s more, this approach, as opposed to a stand-alone recorder, gives you the best of both worlds: the power of code with ease of codeless. The speeds at which you can author mean that meaningful, in-sprint test automation is now a reality. You can find out more on this podcast.
For the insurance industry, the time is now to take another look at your test automation strategy. What’s more, the time is now to look at the next generation of tools and unburden you and future-you from crippling maintenance overhead. The time is now for a tool that delivers in-sprint test automation. The time is now for Virtuoso. Book a demo now!
