Business-driven test automation is an approach that brings business experts from insurance or other specialist departments directly into test automation instead of relying on IT testers alone. It takes low-barrier tools, plain wording without English jargon and continuous coaching, so that business experts can create and maintain stable, risk-based test cases on their own.
Key Takeaways
- Business acceptance tests can only be automated if insurance specialists operate the tool themselves, because no tester can replace their domain knowledge.
- After automation, the acceptance test for a customer project at Signal Iduna runs in three minutes instead of tying up several person-days before every release.
- Technical vocabulary such as the “Triple A principle” shuts business users out; at Signal Iduna, the image of a rail replacement bus service took the place of setup, execute and verify.
- Weekly ensemble testing in a coaching format, where one team member drives and the others navigate, keeps automation knowledge alive across the whole team instead of in a few heads.
- Synthetic test data is the next must-have at Signal Iduna, because the legal separation of data between lines of business otherwise makes it impossible to fully test services that span several of them.
Why Insurers Need Their Business Experts for Testing
At insurance groups, a technical acceptance of software isn’t enough. The German supervisory requirements for IT at insurers (VAIT) call for both technical and business acceptance. And that is exactly where the problem starts.
Business acceptance needs the knowledge of insurance specialists. Testers don’t have that expertise, and they can’t pick it up quickly. Training in insurance takes three years, and what you actually need to know also depends on the line of business.
At a multi-line insurer, the sheer breadth becomes a factor of its own. Jörg Sievers describes the situation at Signal Iduna: around 500 applications, plus a bank and every line of business from motor and transport to health and life. Nobody in development knows the business use cases of all these systems in detail.
The consequence is clear: business acceptance can’t be automated in development. The people who understand the business transactions sit in the business departments, not in the development team.
Low Barrier, Not High Tech: The Tool Has to Fit the Users
When business experts without an IT background are supposed to take on test automation, a low barrier to entry decides between success and failure. The key question is: how simple does the whole thing have to be for ordinary users to use it and actually get excited about it?
When choosing tools, Jörg sticks to one principle: the people who will use the tool later get a say. Two employees with no automation experience but broad business knowledge were given several test tools to try out and got to say which one they liked best.
The tool had to build on a familiar world. In financial services, everyone knows Excel, so the solution needed to head in that direction. Plain Excel was still out of the question, because the documentation has to be audit-proof.
Language matters too. Signal Iduna is a German company more than 100 years old, with many long-serving employees. English technical terms and jargon don’t work there as a basis for teaching.
Wording Changes How People Feel about Testing
The words alone decide whether business experts get on board. Testing often has a negative ring to it, along the lines of “something I have to do.” So instead of talking about testing, the coaches talked about checking quality and about checkpoints.
Technical principles need a clear picture too. The coaches translated the Triple A principle from test automation (arrange, act, assert) into the image of a “Schienenersatzverkehr,” the rail replacement bus service every German commuter knows: setup, execute, verify. It’s an image people understand in Dortmund just as well as in Hamburg.
The advantage of this image is practical. If someone looks at a test case and sees only two lines instead of three, they know immediately that something is missing.
Alongside it comes a fixed sequence, repeated like a mantra until it sticks: first get the test case running, then make it stable, then parameterize it. Only once these principles have become second nature are the teams left to work on their own.
Risk-Based Instead of “100 Records Because We’ve Always Had Them”
Business departments rarely think in test objectives at first. Instead of talking about goals, the attitude is often: “We have our 100 data records here, and those are our test cases.” Ask why, and the answer is: “Because we’ve always had them.”
This is where the risk-based approach comes in. The guiding question shifts to the biggest risk and the business transaction that covers it. Usually, those are the most complex test cases.
That leads to a pragmatic rule of thumb for business testers: instead of working through every test case, the most complex case is often enough, because it happens to cover everything else too. These conversations take place before every project starts, based on a four-pillar model for introducing test automation.
Coaching Instead of Testers for Hire
The method depends on close contact with the team, not on handing work off. Since September, the unit has been operating as a Center of Excellence. Its self-image is clear: not testers you can book, but help for teams to help themselves.
In practice, that means at least one hour of coaching per week with the whole team. The format resembles ensemble testing: one person is the driver and shares their screen, the others weigh in on whether everything is right. The coaches act as navigators and say what to do next.
Everyone takes a turn as driver, so everyone has to carry out the steps themselves. Beforehand, the coaches look at the previous week’s work and collect pointers on what could be improved.
This model holds up when people change. One colleague joined only after automation had started, with no prior knowledge, went through the training and coaching and made it her own. Another employee, who had been skeptical and said “I have zero interest in testing,” decided afterward to keep going in that direction.
Tough Projects First, Not the Harmless Calculator
The team deliberately started with critical systems rather than a side topic. The usual choice would be a small calculator on a website that has nothing to do with other systems. That works fast but doesn’t get you anywhere, because it leaves open how things go when it really counts.
Instead, they picked two projects that matter to the company. One automates the customer portal, where customers submit their documents digitally instead of on paper. The other covers taking out insurance and other products online.
The promise to the teams was concrete, and it put the coaches on the spot: once you’ve built the automation, you’ll never have to do that long manual acceptance run again. Unlike external tool vendors, the internal coaches couldn’t just make this promise. They had to deliver on it.
The result after about three and a half years: no project has been abandoned, and everyone is still as enthusiastic as at the start.
Business-Driven Test Automation: Test the Behavior, Don’t Rush to Green
The most dangerous reflex in test automation is getting to green quickly. That is exactly what the approach Jörg calls Business-Driven Test Automation (BDTA) is designed to prevent. It borrows from behavior-driven development: what gets tested is the behavior of the system, not the shortest route to a green checkmark.
An example makes the difference tangible. A user types “20000” and hits Enter. After a short delay, the system formats it as “20,000.00” and saves exactly that value in the database. A test that enters “20,000.00” directly doesn’t check what happens out there in real use.
The consequence would be serious: if a supplier breaks this formatting feature, the test won’t notice, while users suddenly start saving bad records. Hence the rule: take the application as it is and don’t look for workarounds, such as getting past a locked field.
“We want the behavior of a system to be tested. Automation engineers can always take a back way in. A field is locked? No problem, I’ll get around it. That’s exactly what we don’t want.”
(Jörg Sievers)
How Two Tools Complement Each Other Instead of Competing
Different test tools don’t have to compete. They work at different levels. In the customer portal project, development used Cypress while the business side worked with Sahi Pro. At first, it looked like a rivalry.
The answer was a clear division of labor based on strengths. Cypress works well for a one-page app. But as soon as surrounding systems come into play, something gets uploaded or downloaded, or the flow jumps to another system, the other tool plays to its strengths.
The tool choice also served a communication goal. The team wanted a simple programming language that developers can read right away, and practically every developer knows JavaScript. That way, the same test can be read from two perspectives.
The result of this split is measurable: business transactions that involve other systems stayed with Sahi Pro, a large share moved to Cypress, and since then the acceptance test runs in three minutes before anything goes to production.
Test Data First, Then Configuration, Then Automation
With complex systems, the order of steps decides how efficient you are. In the data-heavy customer portal project, the rule was: sort out test data provisioning first, then everything else.
That produced a staged sequence. First, the test data is generated. Once it’s ready, the system checks its configuration. Only then does the automation start.
The configuration check alone saves one person-day per release. If a complex system starts up with a faulty configuration, everything starts over, and the day is lost.
The automation can also be started selectively. If only one parameter was changed, it’s enough to run the matching group of test cases in Jenkins instead of the full run.
Helping Teams Help Themselves Means Teams Develop Their Own Ideas
A good Center of Excellence makes itself unnecessary in the right places. The unit can’t do everything, so it provides methods, procedures, techniques, tools and in some cases the test environment, rather than doing the work itself.
One concrete task shows how this works. Before a three-week absence, Jörg gave a colleague the job of solving environment detection on his own, meaning recognizing which test system the automation is currently running on. With a few tips and without constant supervision, the colleague pulled it off.
Ideas like that are the real goal. The sequence of test data, configuration check and staggered start also came largely from the teams themselves, not as a rule imposed from outside.
Tool freedom has its limits, though, and for good reason. Every tool in use needs one person responsible for the technical side and one for the business side. That’s why there is a catalog for teams to choose from, instead of a whole zoo of tools like at a startup.
Automated, Manual, Exploratory: What Goes Where
Not everything gets automated, and that’s intentional. Where standardized machine-to-machine communication is involved, such as the industry standard BiPRO for exchanging data with comparison portals, full automation is possible. That is a different kind of test from one through the user interface, though.
Internal applications without interfaces are mostly tested through the user interface, and business departments still run manual tests. Manual testing remains the rule especially where units hand over to business departments outside the agile structures.
Exploratory testing is actively encouraged. In short training sessions over two half-days, the business experts learn test techniques that suit the company, such as equivalence partitioning and boundary value analysis, with practical examples and the reasoning behind them.
Synthetic Test Data and Contract Testing as the Next Levers
Two topics are next on the list. The first is synthetic test data. As a multi-line insurer, Signal Iduna is subject to legal restrictions: people working in life insurance are not allowed to see what the health insurance side processes.
Pseudonymization only half solves this in testing, because the restriction stays in place. Synthetic test data is meant to open up systems for testing, also with a view to future products that span several lines of business. If you’re not allowed to look into the other line of business, you can hardly test such a product otherwise.
The second topic is consumer-driven contract testing. The group is moving from monolithic legacy systems, including WebSphere and 40-year-old COBOL code, to a distributed world of microservices. The agreements between those services have to be secured.
The appeal of contract testing is independence: teams can test on their own without the whole surrounding zoo of systems having to run. What it needs first are projects that apply the approach and convince others with it.
One attitude runs through both topics. In testing, a lot gets solved through pain, even though acting preventively would be cheaper. As Jörg puts it: you can work preventively or reactively, and the second costs more.
Frequently Asked Questions
Why can’t IT testers handle business acceptance testing at insurance companies on their own?
They lack domain knowledge, and it can’t be acquired quickly: Training in the insurance industry takes three years, and specific requirements also depend on the line of business. Insurance companies require both technical and business acceptance. At a multi-line insurer like Signal Iduna (around 500 applications, a bank, and lines of business ranging from auto to life insurance), no one on the development team knows all the business use cases in detail.
What features must a testing tool have for business departments to use it?
It must be easy to use and fit into a familiar environment. In the financial sector, everyone knows Excel, so the search went in that direction; however, using Excel alone was ruled out because the documentation must be audit-proof. The future users helped decide on the selection: Two employees with no automation experience tried out several tools and said which ones they liked best.
How many test cases does a business unit really need?
Significantly fewer than what accumulated data sets might suggest. A common attitude is, “We have our 100 data records here, and those are our test cases,” justified by the fact that they’ve always been there. The risk-based approach, on the other hand, asks for the greatest risk and the business transaction that covers it. Most often, this is the most complex case, which also covers the rest.
How does automation knowledge remain within the team when employees change?
Through regular coaching rather than relying on individual experts. At Signal Iduna, the entire team meets for at least one hour per week using an ensemble testing format: One person acts as the driver and shares their screen, the others provide feedback, and the coaches guide the process. Everyone takes turns being the driver. One colleague with no prior knowledge joined the project this way after it started and was subsequently able to work independently.
Why should an automated test enter data exactly as a real user would?
Because otherwise, the system’s behavior isn’t being tested, only the shortest path to the green checkmark. If a user enters “20000,” the system formats it to “20,000.00” and saves it exactly that way. If the test enters “20,000.00” directly, a broken formatting feature goes unnoticed, while incorrect data records are generated elsewhere. That’s why taking detours around locked fields is also off-limits.
Can the development team and the business unit use different testing tools in parallel?
Yes, if the tasks are divided according to their respective strengths. In the customer portal project, the development team worked with Cypress, while the business unit used Sahi Pro. Cypress works well for a one-pager app; business transactions involving peripheral systems, uploads and downloads, or system jumps are handled by the other tool. With this division of labor, acceptance testing is completed in three minutes instead of taking several person-days.
In what order should test data, configuration, and automation be performed?
First, generate the test data; then, verify the system configuration; only then should you start automation. The configuration check alone saves one person-day per release: If a complex system boots up with a faulty configuration, everything else has to start over from scratch. If only one parameter has been changed, it’s also sufficient to run the appropriate test case group instead of the entire test suite.
Is pseudonymized production data sufficient for testing in a conglomerate with multiple business units?
No, it only partially solves the problem because the legal restrictions remain in place. Life insurance employees are not allowed to see what the health insurance division is processing. Synthetic test data is intended to validate systems, especially for products that span multiple business segments. Otherwise, those who are not permitted to access the other segment’s data can hardly perform thorough testing of such a product.
