Oikocredit

70% E2E test coverage — up from 20%

Test Strategy · Financial Services · Automation

From a failed country rollout to monthly releases across Europe

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.

8 wksTime to first coverage
94%Pass rate at launch
4 hrsDown from 3-day cycles
€0Unplanned downtime post-launch
The Client

Oiko — Impact-first financial services

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.

45Engineers
12Product lines
3 daysManual regression cycle
2019Founded
The Challenge
The Problem

A growing product stuck in manual regression loops

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.

  • 3-day manual regression blocking every release
  • No repeatable test coverage across browsers
  • Junior QA engineers spending 80% of time on repetitive checks
  • No visibility into test results or failure trends

The team knew automation was the answer — they just needed the expertise to get there fast, without hiring a full QA team.

01
Lever 1 · Foundation

Application Health Check

Before writing a single test, we audited the application's testability — selectors, stability, and API contract.

AreaBeforeAfter
data-testid coverage12%94%
Stable selectorsNoneAll critical paths
API contract tests038 contracts
Test environmentAd hocDockerised 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.

02
Lever 2 · Strategy

Risk-Based Test Strategy

We mapped business risk to test priority — covering 20% of journeys that account for 80% of business value first.

14User journeys mapped
6Critical paths automated first
80%Business value covered

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.

03
Lever 3 · Execution

Playwright Automation Suite

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.

Key Engineering Decisions

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.

Selected
Playwright
Multi-browser, fast, excellent debugging
Cypress
Good DX, limited to Chrome
Selenium
Mature but slow, brittle selectors
WebdriverIO
Flexible but complex setup
04
Lever 4 · Integration

Shift-Left QA Integration

Tests were integrated into every pull request, giving developers instant feedback before code merged.

8 minAverage CI run time↓ from 3 days
147Tests in suite+23 added post-launch
0Regression escapes↑ 100% detection

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.

05
Lever 5 · Governance

Go/No-Go Release Gate

A data-driven release criteria framework replaced gut-feel release decisions.

GateThresholdStatus
E2E pass rate≥ 95%Auto-enforced
Critical path coverage100%Auto-enforced
Performance budgetLCP < 2.5sMonitored
Accessibility0 criticalManual + 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.

Results

From 3-day cycles to 4-hour sprints

Eight weeks of focused delivery transformed Oiko’s release process permanently.

↓ 70%70%Regression time reducedFrom 3 days to under 4 hours per release
↑ 94%94%Pass rate at launch147 tests, 138 passing on day one
↑ 5xRelease frequencyFrom 1 per week to daily deploys
→ €0€0Unplanned downtimeZero regression escapes since go-live
↓ 80%80%Manual QA time freedTeam now focused on exploratory testing
↑ 8 wks8 wksTime to first coverageFull pipeline running in under 2 months

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.

Anko Beijleveld

QA Lead, Oikocredit

The Team

Who worked on this

Lead
Senior QA Engineer
80 hrs
Automation
Test Automation Eng.
160 hrs
Strategy
QA Consultant
40 hrs
Delivery
Project Manager
20 hrs
CI/CD
DevOps Engineer
24 hrs
Training
QA Coach
16 hrs
Ready to start?

Let’s build your
automation story

Every team has a regression problem. Let’s fix yours in 8 weeks.

Start the conversationSee more case studies