QA and support

The gap this fills

Small teams are good at building and structurally bad at the week after launch. Not from carelessness — the same people cannot be mid-feature and on call for an incident without one of those jobs losing. The usual result is that testing becomes whatever the person shipping remembers to click, and incidents are handled by whoever happens to see the message.

This is that work, held by someone else, on a retainer rather than a crisis. It is the least glamorous thing the studio sells and the one that most often decides whether a launch holds.

Testing that is worth its upkeep

Automated coverage where it earns its keep: the paths that carry money, data and authentication, and the regressions that have already happened once. A test suite that covers everything equally is a suite nobody maintains, and an unmaintained suite is worse than none because it teaches the team to ignore red.

Manual testing for everything automation is bad at — layout under real content, right-to-left rendering, the behaviour of a form when someone pastes in something strange. Bilingual products need the manual pass in both languages; an Arabic layout can break in ways an English test run will never see.

Release QA is a defined gate, not a vibe. A checklist tied to what actually changed, run before the release rather than discovered after it.

On call, with triage that means something

Incidents get a response, a diagnosis and a fix, in that order, with the severity judged against your users rather than our convenience. Bugs get triaged — which is mostly the discipline of saying out loud that something is not going to be fixed this month, instead of letting it sit in a backlog pretending otherwise.

Quiet fixes are part of the retainer: the small things that never clear the bar for a sprint and slowly make a product feel unmaintained.

What the retainer covers

• Automated test coverage on the paths that carry money, data and authentication.
• Manual release testing in both languages, including right-to-left layout.
• A defined release gate run before each deploy.
• Bug triage with an honest not-this-month list.
• Incident response, with a written account afterwards of what happened and what changed.

Why we take this seriously

Omaraty handles a building's shared money — dues collected from residents, expenses approved against receipts, a ledger people argue over. A product like that does not get to be flaky. The habits on this page come from running our own software in production, not from a methodology.

Omaraty case study

Common questions