Ebenezer Osei-Bonsu
Back to all work

Case study · Fintech · Fido

Fido App

mobile lending and financial services

Ownership: Team · Senior QA

My role: Senior QA Engineer at Fido Micro Credit, as part of the engineering team.

Sector
Finance & public finance
Context
Fido Micro Credit
Ownership
Team · Senior QA
Fido App home screen on a phone, with an instant-credit offer, an EasySave savings balance and a buy-now-pay-later phone offer.
Fido App home screen for a new user, with a prompt to finish account setup before borrowing, an EasySave savings offer and phone financing.

Real screenshot · seeded test data

01 — What it was

Fido’s mobile app for instant credit, savings and other financial services, used in Ghana, Uganda, Zambia and South Africa.

02 — Why it mattered

People rely on it for their money, in four countries, so a release that breaks costs real users.

03 — My role

Senior Quality Assurance Engineer at Fido Micro Credit, working inside the core engineering team. I didn’t build the app.

04 — Technical problems

UI testing was entirely manual (only the backend had automated tests), runtime bugs were hard to isolate in an existing codebase, and checks had to run on every release rather than by hand.

05 — What I did

Asked by my manager to start automated UI testing, I set it up from scratch with Maestro (mobile) and Playwright (web) and brought my QA teammates on board. Used agentic tools to audit the existing architecture and isolate runtime bugs. Designed and maintained the automated suites. Integrated them into the CI/CD pipeline. Wrote QA manuals and test configurations, tracked issues in Jira, and supported UAT, production validation, test planning and estimation.

06 — Tools

Maestro, Playwright, CI/CD, Jira, agentic AI tools

  • Maestro
  • Playwright
  • CI/CD
  • Jira

07 — Result

The QA team moved from manual-only UI testing to automated UI suites that run in the release pipeline, and the app is live in four countries.

08 — What I learned

Working inside the core engineering team showed me that tests do the most good when they run in the pipeline on every change, not as a separate step at the end.