A test suite can quickly grow into a second system your engineers have to maintain. In financial services firms and insurance firms, that work may span customer portals, payment APIs, core platforms, and employee workflows. Teams need to maintain these connections while delivering new features, and sometimes, it can seem like the test suite is growing faster than the team that’s keeping it functioning
Financial services engineering teams can scale automation without sacrificing delivery capacity by reducing the time spent building and maintaining test frameworks, reusing tests where they fit, and choosing the right approach for each system. The first step is understanding what makes the work pile up, assigning clear ownership for keeping it healthy, and choosing tools that let teams reuse what’s already been built. We examine these issues and more below.
Why does test automation take more engineering time as it grows?
Test automation takes more time as it grows because engineers often need to maintain frameworks, fix tests after application changes, or rebuild similar coverage. That work can accumulate quietly: one suite for a customer portal, another for policy servicing, plus custom connections to make results useful. Each piece may seem manageable. Together, they can take a meaningful bite out of engineering capacity.
AI can help developers move through individual tasks faster, but it doesn’t necessarily guarantee faster delivery across an organization. DORA’s 2025 State of AI-Assisted Software Development, released in March report found that, while 80% of technology professionals feel that AI has increased their productivity, 30% have little to no trust in the code that AI produces.
This prompts what DORA calls a “hidden verification tax.” One developer told DORA, “I feel somewhat more productive, but it’s at a cost. While I end up spending less time writing code, I spend more time babysitting the AI and reviewing what it is trying to do.” So, speeding up one part of the work doesn’t necessarily speed up the whole process.
Some of the burden also comes from the individuals who can maintain automation within the organization in the first place, especially if it’s a small group.
What happens if only a few engineers know how to maintain a test suite?
If only a few engineers know how to maintain your test suite, the team can become dependent on their time and informed knowledge. That might work until they’re busy with another priority, move teams, or leave the organization. Then, a suite that looked like an asset can become a queue of work only a few people know how to handle.
To prevent this, examine the following:
- How many people can understand and update the tests
- How much coverage is reusable
- Whether releases depend on one or two specialists
Shared patterns and broader ownership make it easier to keep coverage useful as priorities change. They can also make it clearer where teams are repeating effort, which is a good place to look for opportunities to reuse tests.
| Leapwork helps financial services and insurance firms confidently validate critical processes across complex estates, while maintaining strong governance, ensuring critical business continuity, and accelerating release velocity. See how we do it. |
How can you reuse tests across similar banking or insurance processes?
You can reuse tests across similar processes by looking for steps that repeat across journeys such as onboarding, account servicing, claims, or policy updates. A common identity check or approval step, for example, may be a candidate for reuse across related workflows.
Reuse means avoiding repeated setup and maintenance when the underlying steps are similar, not forcing every process into the same test. When they’re used thoughtfully, reusable components give teams a starting point on which to build, instead of recreating the same work for each journey. Once teams know what can be shared, they can decide which automation approach fits each part.
Should teams use Playwright, visual automation, or both?
Financial services engineering teams should use whichever automation approach best fits the application, the process, and the people maintaining it. Playwright is a strong choice for web testing when you have engineers who can write and maintain code. Visual automation lets anyone on the team map a business process step by step and see exactly what’s being tested, so the people who understand the process can automate it and get the same reliable results.”
Consider a change to online banking that also affects an employee process or a core system. One testing method may not be ideal for every step. Different approaches can work side by side, as long as teams can manage ownership and understand what their coverage says about a release. That’s where a way to govern and connect those approaches becomes especially useful.
How does Leapwork help teams govern Playwright and extend coverage beyond the browser?
Leapwork helps teams govern Playwright and extend coverage beyond the browser through Leapwork Play and Leapwork Flow. Play can import existing tests and GitHub source code, then add governance, reusable components, and audit trails around Playwright-based validation. Flow provides visual, no-code automation across web, desktop, mainframe, and packaged applications, with reusable subflows for connected processes.
Both give teams options for building on existing test frameworks, covering workflows that reach into other systems, and establishing governance throughout all. The best fit depends on the applications, processes, and maintenance needs in your environment.
