Six months ago, a mid-sized NBFC client came to us with a problem that’s painfully common in BFSI: their QA team was spending more time running regression suites than actually finding meaningful bugs. Every release cycle meant 3-4 days of manual + automated testing, and even then, critical issues were slipping into UAT. By the time we were done reworking their QA pipeline, bug detection time dropped by 60%. This post is about how we actually got there — not the marketing version, the real one.
The problem wasn’t “not enough testing”
When we audited their existing setup, the issue wasn’t a lack of effort. Their team had a Selenium-based regression suite with over 1,200 test cases covering loan origination, KYC verification, and repayment workflows. The problem was that every single release ran the full suite, regardless of what had actually changed in the code. A one-line fix to an interest calculation module triggered the same 6-hour test run as a major UI overhaul.
In BFSI specifically, this gets worse because of compliance-driven regression requirements — you can’t just skip testing on payment or KYC modules, even for minor changes. So teams end up over-testing everything to stay safe, which slows releases without actually improving defect detection.
What we changed
We didn’t rip out their existing automation stack — that would’ve been expensive and risky for a regulated client. Instead, we layered intelligence on top of it in three specific ways:
- Risk-based test prioritization: We built a model trained on 14 months of their git commit history, past defect data, and test execution logs. It flags which test cases are most likely to catch a bug based on which files/modules changed in a given PR. Instead of running all 1,200 tests, high-risk changes trigger 300-400 targeted tests first, with the full suite running overnight.
- Self-healing locators for UI tests: Their biggest maintenance headache was brittle Selenium scripts breaking every time a developer renamed a div or changed an ID. We implemented locator strategies that use multiple attributes (text, position, DOM hierarchy) so scripts adapt when the UI changes slightly, instead of failing and needing a QA engineer to fix the script manually.
- Visual regression + log anomaly detection: For their payment confirmation screens, we added visual diffing that catches rendering issues pixel-selection tools miss — like a misaligned CTA button after a CSS change. Separately, we fed application logs from staging into an anomaly detection model that flags unusual error patterns before they show up as a reported bug.
The payment gateway example
A second client, a payment aggregator processing UPI and card transactions, had a recurring issue: intermittent failures during peak load that only showed up in production, never in their test environment. Manual log review after an incident could take a QA engineer half a day just to trace the failure back to a root cause.
We set up log-pattern clustering that groups similar error signatures together and compares them against historical incident data. When a new anomaly cluster appears that resembles a past production issue, it gets flagged immediately instead of waiting for a customer complaint or a manual log audit. Their mean time to detect transaction failures dropped from roughly 4 hours to under 90 minutes.
The actual numbers
- Full regression cycle time: reduced from 6 hours to 2.5 hours for standard releases
- Critical bugs caught pre-UAT: up 35%, meaning fewer issues reaching the compliance/business testing stage
- QA engineer hours spent on script maintenance: down roughly 45% per sprint
- Overall bug detection time (commit to confirmed defect): down 60% on average across both clients
What didn’t work, honestly
Not everything was smooth. The risk-based prioritization model needed about 6 weeks of tuning before the QA lead trusted its recommendations enough to skip full suite runs during the day. We also learned that self-healing locators aren’t magic — they still fail on genuinely broken UI, which is the behavior you actually want, but it took some convincing for the team not to see every alert as a false positive.
We also tried applying the same anomaly detection approach to their core banking batch jobs early on, and it didn’t work well — batch processes don’t generate the kind of granular log patterns the model needed. We scoped that out rather than forcing a fit.
What this means if you’re evaluating QA investment
If you’re a BFSI or fintech decision-maker looking at your own QA bottlenecks, the question worth asking isn’t “should we add AI to testing.” It’s narrower: where specifically is your team losing time — full regression runs on every change, flaky UI scripts, or slow incident root-causing? Each of those has a different fix, and bolting on a generic AI testing tool without mapping it to your actual bottleneck usually just adds another layer of maintenance.
At Speqto, this is the approach we take with every QA engagement — audit first, automate what’s actually slow, and measure against real release metrics, not vanity dashboards. Happy to walk through what this could look like for your test suite specifically.
