Two of our nine people do nothing but test. They write the cases, run them by hand, automate the parts worth automating, and sign off every release before it reaches your users. Seven platforms across three countries have gone out that way.
In a team of nine, it is tempting to let developers test their own work and call it done. We decided early on not to do that. Two of our people are QA engineers and nothing else — they sit outside the feature work, they write the test cases from the spec rather than from the code, and a release does not go out until one of them has signed it off. It slows a few things down. It has also kept a lot of embarrassing Friday evenings off the calendar.
The systems we work on are not the kind you can check by eye. Bright Future takes real money through MyFatoorah and streams paid video from Bunny CDN to students in Kuwait. Cargonio files invoices into PRA and FBR tax systems, where a wrong figure is a compliance problem rather than a bug. DVM Central and VetPet Central serve US clinics on web and mobile at the same time. Each of those needs a written, repeatable regression pass before anyone clicks deploy, and that is what our QA team maintains.
Test cases written from your requirements, run by hand against staging, with results recorded per build. Alongside that, deliberate exploratory sessions where QA goes looking for the awkward paths nobody wrote a ticket for — wrong order of steps, expired sessions, half-filled forms, back button abuse.
Every confirmed bug becomes a permanent test case, so the same fault cannot come back quietly two releases later. The suite is versioned with the product and split by area — auth, checkout, content, reporting — so a small release only re-runs what it can plausibly have broken.
React Native apps get tested on physical iOS and Android handsets, not just simulators, because that is where permissions, video playback and device-limit rules actually misbehave. Builds go out through TestFlight and Play internal tracks so you and your stakeholders can try the same build QA passed.
We automate the parts that are stable and expensive to check by hand: PHPUnit feature tests over Laravel API endpoints, business rules like coupon stacking, installment schedules and tax calculations, and data integrity checks. We do not automate screens that are still changing weekly — that is a maintenance bill, not a safety net.
Checkout is where bugs cost you directly, so it gets its own attention. We test Stripe and MyFatoorah flows in sandbox end to end — success, failure, timeout, duplicate callback, refund — and verify the order, invoice and accounting entries that follow, including PRA and FBR submissions on Cargonio.
Every defect gets steps to reproduce, environment, build number, severity and evidence, so a developer can start fixing rather than start guessing. Fixes are verified on staging, the affected regression set is re-run, and QA issues a written sign-off with any known issues listed rather than buried.
Before writing a single case, QA goes through the requirements, the existing screens and the data model with the tech lead. Testing a fee calculation or a cargo manifest properly means understanding what the right answer looks like, not just that a page loads.
You get the test cases and the scope in writing — what will be covered, on which browsers and devices, and what is deliberately out of scope. If you disagree with the priorities, that is a cheap conversation to have at this stage rather than after a release.
QA runs the plan against staging and logs defects with reproduction steps and evidence. Developers fix, QA verifies, and anything not fixed stays visible on the list with a severity next to it. Nothing gets closed because it was hard to reproduce.
A release goes out with a written pass from QA and a short note of known issues. New bugs found in production are added to the regression suite so the next release is a little safer than the last one.
Send us the one flow you hold your breath over — checkout, enrolment, payroll, invoice sync. We'll tell you where it is most likely to break and what a test plan around it would cover.