QA & Testing ยท Fintech

Playwright E2E and API test suite for a Romanian fintech app.

94 automated tests covering critical user journeys, API contracts, and load scenarios. A 5-day manual regression cycle reduced to under 2 hours, gated on every PR.

94
automated tests
5dโ†’2h
regression time
0
missed regressions post-deploy
8 wks
delivery
Feb 10, 2026 ยท 10 min read QA maturity model: from manual to automated Read โ†’ Feb 24, 2026 ยท 13 min read GitHub Actions CI/CD for self-hosted infrastructure Read โ†’
Feb 24, 2026 · 12 min

Passkeys and WebAuthn in 2026: implementation guide

The WebAuthn authentication flows tested in this engagement โ€” registration, authentication, and cross-device passkey scenarios โ€” and how Playwright handles credential creation in a headless browser.

Read →

Background

A Bucharest-based fintech startup had built a personal finance app โ€” budgeting, bank account aggregation, and spending analytics โ€” that had grown from a side project to 40,000 monthly active users over 18 months. The team of six developers released weekly, but each release required a five-day manual regression cycle that tied up two developers and frequently delayed shipping.

The problem wasn't just time โ€” it was coverage. The manual regression checklist had grown to 200+ steps, but it was inconsistently applied. Critical user journeys (bank connection, transaction categorisation, budget tracking) were sometimes skipped when deadlines loomed. Three separate production incidents in the previous quarter had all been regressions that a complete manual pass would have caught.

The team had attempted to write Playwright tests internally twice before. Both attempts stalled โ€” the first because the tests were brittle against minor UI changes, the second because the test suite wasn't integrated into CI and tests were only run manually when someone remembered. They needed someone to build a suite that would actually work and stay working.

Approach: coverage-first, then CI integration

We started by mapping the critical user journeys โ€” the flows that, if broken, would directly cause user-visible failures or financial data errors. For a personal finance app, this translated to seven core journeys: account connection (OAuth + screen scraping paths), transaction sync, manual transaction entry, categorisation (automatic and manual), budget creation and tracking, spending reports, and account settings. Everything else was secondary.

The test architecture used the Page Object Model to insulate tests from UI implementation details. Each page had a corresponding Page Object class that exposed high-level actions (connectBank(), createBudget()) rather than raw selectors. When the UI changed, only the Page Object changed โ€” not every test that touched that page. This was the specific pattern that had caused their previous attempts to become unmaintainable: tests were written directly against selectors with no abstraction layer.

We split the 94 test cases into three tiers. Tier 1 (31 tests) covered the seven critical journeys end-to-end โ€” these ran on every PR and blocked merge if any failed. Tier 2 (43 tests) covered secondary flows (report exports, notification settings, edge-case budget rules) โ€” these ran nightly. Tier 3 (20 tests) was the API contract layer: every endpoint used by the frontend had a contract test ensuring it returned the expected schema, status codes, and error responses. API contract failures didn't block PR merge but triggered a Slack alert.

"We'd tried to write Playwright tests ourselves twice. They worked for a week and then became a liability โ€” every UI change broke ten tests. What 47Network built has been running for four months without us touching the test code once. That's what we actually needed."

โ€” CTO, Confidential Fintech Client (Bucharest)

Load testing with k6

The bank connection flow involved a third-party aggregation API that the team had never load-tested. During peak usage (typically Monday mornings when users checked their weekend spending), the app would fire dozens of aggregation API calls simultaneously. We used k6 to simulate concurrent user connections at 5ร—, 10ร—, and 25ร— their current peak load โ€” the 25ร— scenario revealed a connection pool exhaustion bug in their aggregation client that would have caused a production outage at their projected 6-month user count.

CI integration and ownership transfer

The CI pipeline ran Tier 1 tests on every PR using GitHub Actions with a self-hosted runner inside the client's network (necessary because the test environment wasn't publicly accessible). A failing test blocked merge โ€” no exceptions, no manual overrides. We configured Playwright's built-in HTML reporter plus a GitHub Actions summary that showed failing tests with screenshots directly in the PR review interface.

Ownership transfer was taken seriously. We ran two pair-programming sessions where a developer from their team wrote new tests alongside us. By week 7, they had independently added 8 tests for a new feature they were building. The documentation included a "test writing guide" calibrated for their specific stack (Next.js web app, React Native mobile, Node.js API), with examples drawn from the actual test suite.

5dโ†’2h
regression cycle (5 days โ†’ under 2 hours)
0
production regressions in 4 months post-deploy
1
critical load bug found before production
8
new tests written by client team independently

Four months after delivery, the team had expanded the suite to 112 tests โ€” all written independently, using the Page Object Model patterns from the original suite. The 5-day regression cycle has not returned.

Delivery timeline

01

Discovery & journey mapping โ€” Week 1

Critical user journey identification (7 core flows), codebase review, test environment setup. Page Object Model architecture design. CI pipeline assessment.

02

Tier 1 E2E tests โ€” Weeks 2โ€“4

31 critical-path tests covering all 7 core user journeys. Page Object classes for all major screens. Test data factory for deterministic test state. Initial CI integration.

03

Tier 2 + API contract tests โ€” Weeks 4โ€“6

43 secondary flow tests. 20 API contract tests for all frontend-facing endpoints. k6 load test scenarios. Connection pool bug identified and reported.

04

CI hardening & pair programming โ€” Weeks 6โ€“7

PR gate configuration, Playwright HTML reporter, GitHub Actions summary integration. Two pair-programming sessions. Test writing guide drafted.

05

Handover โ€” Week 8

Final documentation, runbook delivery, team review session. Client team ran their first independent test-writing sprint. 30-day support window.

← All Case Studies SaaS QA pipeline →
Feb 25, 2026 · 11 min

JWT and token authentication: a practical security guide

The Playwright authentication fixtures in this engagement use the JWT refresh flow โ€” storing tokens in HttpOnly cookies, testing token rotation, and verifying the alg:none rejection.

Read →