Quality as a Release Gate, Not a Phase

Teams still talk about a QA phase, as if quality were a stop the build makes once. By then, defects are already expensive. We treat quality as a series of gates, and each one must pass before the work moves closer to production.

1. 01Define done before work starts

   Acceptance criteria, edge cases and performance expectations belong in the ticket, not in a chat thread after the merge. When “done” is fuzzy, every gate becomes a negotiation.

2. 02Automate the checks a machine can do

   Unit, integration and acceptance tests should run on every change. BuffyHub was covered at all three levels. On Truck-4, SonarQube runs in the Azure DevOps pipeline and flags risky code before review, and every uploaded file is scanned with ClamAV before it is accepted.

   ATC’s .NET code is tested with xUnit, run in Docker so the tests behave the same on every machine.

3. 03Keep people on the risky parts

   Scripts check what you already know. People find what nobody thought of. Money movement, sign-in, permissions and anything that deletes data get a human check on real devices before release.

4. 04Test the failure paths, not just the happy path

   Payments retry, networks drop and users double-click. On the Luxe Excursions booking platform, each staff alert goes out once per booking, so a payment retry never sends a duplicate.

5. 05Close the loop after release

   A release isn’t finished when it deploys. Check the key flows in production and watch the numbers. On Luxe Excursions, the data showed half of all giveaway entry attempts were failing, mostly on phones. After the fix, the next 14 entries all went through.