Quality is a gate. Not a phase.
If testing is something that happens after the build, it is the first thing cut when the date slips. We make it the condition of merging instead.
The problem
The traditional shape puts QA at the end, which guarantees two things. Defects are found at their most expensive moment, and the whole activity becomes negotiable the instant a deadline gets close.
We invert it. The tests come from the spec, and they are written before the build rather than after it. A test written from the spec asks whether the implementation does what was required. A test written from the finished implementation only asks whether the implementation does what it does. Those tests run as a gate on every merge, so work that does not pass does not merge, which takes the decision out of anyone's hands at 6pm on a Friday.
The result is not zero defects, because nothing produces zero defects. It is that the defects you get are the interesting kind, found early, rather than a regression in a feature that worked last month.
- Tests written from the spec, before the build, not from the finished code
- A second, independent check that the code matches the spec, not just itself
- Automated review and quality gates on every merge
- Regression suites that grow with the product instead of rotting
The failure mode AI-First delivery has
This is the part most AI development pitches leave out, and it is the reason our QA discipline looks different from a traditional one.
When an engineer asks an agent to build a feature, the agent will happily produce the implementation and the tests in the same pass, from the same reading of the spec. If that reading was wrong, the implementation is wrong and the tests pass anyway. Nothing in the pipeline objects. The code is confidently, verifiably wrong against a standard it wrote for itself.
That is not a bug in the model. It is a structural property of any system that generates the work and the check together. Speed makes it worse, because the wrong thing gets built on top of before anyone re-reads the requirement.
So we break the loop deliberately. The scenarios are defined from the spec before implementation starts, by someone other than whoever drives the build. After the build, a separate set of checks verifies the spec requirements the build's own tests did not cover, written by a different person for a different purpose. Two authors, two intents, and a real chance of catching the misreading.
- Scenarios defined from the spec before the build, not derived from the finished code
- A separate compliance pass written by someone other than the build author
- Particular attention where an agent plausibly diverges: data scoping, authorization, default state, negative paths
- Authorization checked at the API and data layer, not only where the UI hides the button
Who owns what, and when
The judgment that cannot be automated is deciding what must be proven and where an agent is likely to go wrong. That is a different job from writing the tests, so it belongs to a different person.
| Dimension | Defined before the build | Built and checked after |
|---|---|---|
| What must be proven | The behavior contract: happy path, validation rules, edge cases, accessibility | Implemented as tests at whichever layer proves it most cheaply |
| How serious a failure is | A severity per scenario, agreed upfront | What gets fixed first when something goes red |
| When it runs | Smoke, full, or regression, decided per scenario | Wired into the pipeline as a gate |
| Where an agent might diverge | Noted per scenario, in advance | Targeted by an independent compliance check after the build |
| Which stack layer | Deliberately not decided here | The engineer's call at build time: unit, component, integration, end to end, or visual |
Automation is no longer the expensive part, so a plan that stops at "we will write tests" is not a plan. Deciding what to prove is the work.
What this covers
Automated regression
A suite that runs on every change and is maintained as part of the work.
Performance and load
Stress testing and scalability validation against real expectations.
Device and hardware QA
Bluetooth, IoT, payment terminals, and NFC on real hardware.
Security testing
Vulnerability assessment and penetration testing by specialists.
Accessibility
WCAG verification treated as a requirement, not a retrofit.
Quality reporting
What is covered, what is not, and what changed this cycle.
The pyramid, and what gates on it
Test strategy here is shaped like a pyramid, which is unfashionable to say and still correct. Many fast unit tests, fewer integration tests where components meet, and a thin layer of end-to-end tests covering the journeys that would cost you money if they broke.
The inversion is what goes wrong elsewhere. A suite that is mostly end-to-end tests is slow, flaky, and eventually ignored, and an ignored suite is worse than no suite because it produces false confidence. So we keep the expensive layer thin on purpose.
All of it runs as a gate. Linting, unit, integration and end-to-end run in the pipeline, and work that does not pass does not merge. On phase acceptance the coverage thresholds are explicit numbers rather than a promise: at least 70% unit and at least 50% integration on the code we wrote, measured against our code rather than inflated with vendored libraries.
- Unit, integration, then a deliberately thin end-to-end layer
- Linting and every test tier running as a merge gate, not a nightly report
- At least 70% unit and 50% integration coverage on Koombea-authored code at phase acceptance
- Coverage measured on our code, never padded with third-party libraries
- A higher bar on the paths that carry risk: authentication, authorization, payments
- No P1 or P2 defect open at handoff, which is a hard gate rather than a target
A gate that does not fail the build is decoration
Every pipeline we run enforces the same baseline before anything merges: linting at zero errors rather than zero blocking errors, type checking with no suppressions, the unit suite passing, a coverage floor, static analysis, and a dependency scan for known vulnerabilities.
The rule that matters is that the gate has to be able to fail. A check that is installed but not enforced tells you nothing and trains everyone to ignore the red. If we ever disable one, the reason and the date it goes back on are written down.
We also check the artefact rather than the exit code. A test command that runs zero tests exits successfully, and a pipeline reporting green having executed nothing is worse than no pipeline, because it manufactures confidence. So the gates assert that the output exists and has the shape it should, not merely that a command returned zero.
- Lint, types, unit suite, coverage floor, static analysis, dependency scan
- Every gate blocks the merge, or it is not a gate
- Test runs assert a plausible test count, so a silent zero cannot pass as green
- A disabled gate carries a written reason and a date to restore it
The toolkit, named
Browser and mobile automation
Selenium and Appium for cross-browser and real-device coverage.
End-to-end
Cypress for the journeys whose failure would cost you money.
Load and performance
JMeter against your expected volume and burst pattern, not a round number.
Traceability
BDD with Cucumber and Gherkin where a requirement has to be provably tested.
AI-First test design
Tests generated from the same spec that drives implementation, then reviewed.
Our own test management
Built and operated in house rather than rented, and it is why the reporting is specific.
What drives the estimate
Quality is not a separate line item here, because tests are generated from the spec that drives the build. So the question is not what QA costs. It is what raises the coverage bar, and that is worth knowing before you choose a scope.
- Regulated data or money movement, which raises the required coverage rather than the feature count
- The device and browser matrix you actually need to support, which is usually smaller than the one requested
- Physical hardware in scope: Bluetooth, NFC, payment terminals and IoT need real devices, not simulators
- Whether an accessibility conformance level has to be verified and evidenced
- Role and permission combinations, which multiply test surface faster than anything else
Questions worth asking
Can we just skip the tests to hit a date?
We have no tests at all. Where do you start?
Is manual testing gone?
Does 70% coverage mean 70% of bugs are caught?
Who runs penetration testing?
Credentials behind the quality gates
Our teams hold ISTQB and Certified Agile Tester credentials, and Koombea's software design and development unit has been appraised at CMMI-DEV/3.
Bring us the backlog.
In 30 minutes, we will show you what a Pod would ship first and how we would price it.