
70% E2E test coverage — up from 20%
Test Strategy · Financial Services · Automation
How spriteCloud turned a broken QA process into a risk-based quality system and enabled one of Europe’s oldest impact investors to release software monthly instead of every 3–6 months.
Oiko is a Dutch financial services company focused on responsible investment products. Their small but ambitious engineering team faced a classic scaling problem: every release required 3 full days of manual regression testing, blocking both speed and confidence.
Oiko's QA process had grown organically and hadn't scaled with the product. Three full days of manual testing per release meant the team could ship at most once per week — and even then, coverage was inconsistent.
The team knew automation was the answer — they just needed the expertise to get there fast, without hiring a full QA team.
Before writing a single test, we audited the application's testability — selectors, stability, and API contract.
| Area | Before | After |
|---|---|---|
| data-testid coverage | 12% | 94% |
| Stable selectors | None | All critical paths |
| API contract tests | 0 | 38 contracts |
| Test environment | Ad hoc | Dockerised CI |
We ran our proprietary Testability Scan across all 14 user journeys. Fewer than 15% of interactive elements had stable selectors — a fundamental blocker for reliable automation.
In the first two weeks, the Oiko dev team added data-testid attributes to all critical paths, guided by our prioritised selector map.
We mapped business risk to test priority — covering 20% of journeys that account for 80% of business value first.
Rather than automating everything at once, we used a risk-weighting matrix to identify which journeys had the highest impact if broken. Investment onboarding, portfolio rebalancing, and reporting were prioritised.
This meant coverage that mattered was live within the first sprint, giving the team immediate confidence to ship.
We built 147 end-to-end tests in Playwright, integrated into the existing CI/CD pipeline from day one.
The suite covers the full investment lifecycle: onboarding, portfolio management, transaction flows, and reporting. Tests run in parallel across Chrome, Firefox, and Safari.
We chose Playwright over Cypress for its multi-browser support and network interception. Tests are structured by user journey — not by page — making them resilient to UI changes.
Page Object Model keeps the suite maintainable as the product evolves.
Tests were integrated into every pull request, giving developers instant feedback before code merged.
We integrated the suite into GitHub Actions, running on every PR against a staging environment. Failing tests block merge — a contract the team agreed to upfront.
We also trained three of Oiko’s engineers to write and maintain tests, so the team can grow the suite independently.
A data-driven release criteria framework replaced gut-feel release decisions.
| Gate | Threshold | Status |
|---|---|---|
| E2E pass rate | ≥ 95% | Auto-enforced |
| Critical path coverage | 100% | Auto-enforced |
| Performance budget | LCP < 2.5s | Monitored |
| Accessibility | 0 critical | Manual + auto |
The Go/No-Go gate formalised what had previously been a vague process. Now every release has a clear pass/fail signal based on objective criteria.
The release manager dashboard shows test results, coverage stats, and performance metrics in a single view — making the release decision in under 5 minutes.
Eight weeks of focused delivery transformed Oiko’s release process permanently.
They rewrote an automation suite in two weeks that had taken our previous team nearly a year to build. Speed like that comes from knowing exactly what you’re doing and why.
QA Lead, Oikocredit
Every team has a regression problem. Let’s fix yours in 8 weeks.
Start the conversationSee more case studies