All servicesService · QA & Testing

Ship releases without holding your breath

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.

Start a project See our work
In-house QATesters separate from the build team
Manual + autoExploratory passes and regression suites
Sign-off gateNothing ships without a QA pass
Written planswhat we test, and what we deliberately do not
Overview

Testing is somebody's job here, not the last hour of a sprint

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.

  • Dedicated QATwo engineers who only test
  • Written test casesEdge cases too, not just happy paths
  • Release sign-offNothing ships without a QA pass
  • Regression suitesRe-run before every release
What's included

What you get with QA & Testing.

01

Manual and exploratory testing

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.

02

Regression suites that keep growing

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.

03

Mobile testing on real devices

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.

04

Automated tests where they pay for themselves

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.

05

Payments, integrations and money paths

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.

06

Bug triage and release sign-off

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.

How we work

From first call to live.

01

Understand the product first

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.

02

Write and agree the test plan

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.

03

Test, report, retest

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.

04

Sign off, then keep the suite alive

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.

Tools we use

The stack behind the work.

PHPLaravelPHPUnitLaravel PintTypeScriptReactNext.jsReact NativeMySQLDockerSentryTestFlightStripe & MyFatoorah sandboxes
Questions

Things clients ask us.

Do we need automated tests, or is manual testing enough?
Most products need both, in different proportions. Automation earns its keep on the flows you run every release and cannot afford to break: login, checkout, payment callbacks, role permissions, because a machine re-runs them for free. Manual and exploratory testing catches what no script thinks to ask: the odd layout on a small screen, the confusing error message, the state nobody planned for. The honest trade-off is timing, since automating a screen that is still being redesigned weekly means paying for it twice, so we hold off until the flow settles.
When in the project should testing actually start?
Before code, ideally. A tester reading the acceptance criteria will find contradictions and missing cases while they still cost nothing to fix: what happens if a coupon expires mid-checkout, what an instructor can see that a student must not. Bring us in at the end and we will still test properly, but expect some findings to be design decisions rather than defects, and those are the expensive kind to change late.
What does a test plan cover, and what does it leave out?
It names what we are testing, on which browsers, devices and environments, with what data, and what has to pass before a release goes out. It also fixes severity levels up front, so "critical" means the same thing to your team and ours. What it deliberately leaves out is exhaustive coverage of every possible combination: that is not achievable at any budget: along with load and performance work unless you commission it separately. For third-party systems such as payment gateways or government tax endpoints, we test our integration and how it behaves when they fail, not their service itself.
What happens once you find a bug?
It gets written up with reproducible steps, environment, build number, and a screen recording or log where that helps, then triaged for severity and passed to the engineer who owns that area. The fix goes on a branch and is retested by the person who raised it, on the environment where it failed: a bug closes on verification, never on a developer saying it is done. If we have seen that failure before, a regression check joins the suite so it cannot come back quietly. Cosmetic, low-severity items are often batched into a later release; that call is yours, and we will tell you which ones we think can wait.
Who keeps the automated tests working as the product keeps changing?
We do, for as long as we are engaged. Test updates go into the same pull request as the change that broke them, rather than a backlog nobody clears, and flaky tests get fixed or deleted: a suite people have learned to ignore is worse than no suite. If you take the work in-house, we hand over the CI configuration, the Docker setup that runs everything, and a short runbook. Be realistic about what follows: without a named owner, an automated suite degrades within a couple of release cycles.
More from us

Other services.

Custom SoftwareAI & AutomationWeb ApplicationsMobile AppsCRM SolutionsCloud & DevOps

Tell us what broke in your last release

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.

Start a project Chat on WhatsApp