Shift-Left QA: Where to Start

Shift-left is an easy phrase and an awkward practice. Teams hear it as testing earlier and end up running the same cases a week sooner. The useful version starts before any test exists — with the questions asked while a feature is still being described.

In many projects we join, QA sits at the end of the chain. A feature is designed, built and handed over, and only then does someone ask what should happen when the network drops or a payment is declined. By that point every answer means rework. Moving QA earlier is less about tools and more about changing when those questions get asked.

Start with acceptance criteria, not test cases

When QA reads requirements together with the team, most ambiguity surfaces in minutes: what happens on a failed payment, which states an empty screen has, what the API returns when an upstream service is down. Every answer written down at that point is a defect that never reaches a developer, let alone a user.

A simple rule helps: if nobody can say how a criterion will be checked, it is not ready for development. “Transfers should be secure” is a wish. “A user without the right permission gets an error and no transfer is created” is something a developer can build and a tester can verify.

Ask the uncomfortable questions early

A short refinement session with QA in the room usually covers the same ground:

• Failure paths. What does the user see when something goes wrong, and what state is the data left in?

• Permissions. Who should not be able to do this, and how do we prove they can’t?

• Data. Which inputs are realistic, which are edge cases, and where will the test data come from?

• Environments. Can this be tested before release at all, or does it depend on a third party we can’t reproduce?

On a FinTech product with money transfers and in-app messaging, these questions shaped the work more than any test plan did. Authentication and permission rules were agreed and written down before the code, so the automated checks around them were built in the same sprint instead of added after an incident.

Agree what “good enough” means before you build

Some features don’t have a single correct answer. On an AI product whose model outputs varied from run to run, a pass-or-fail test simply didn’t work. What did work was deciding upfront — product, data science and QA together — what an acceptable answer looks like, collecting a golden set of reference cases and agreeing quality thresholds before the next model version was ready. The release conversation became a comparison against something everyone had already signed off, not a debate about impressions.

The same idea works for ordinary releases. Clear entry and exit criteria — what must be true before testing starts, and before a build ships — remove most late-stage arguments about whether something is “ready”.

Keep the loop short

After that it is mechanics: testable acceptance criteria, a shared definition of done, and automated checks added in the same sprint as the feature. None of this requires a new tool — it requires QA in the room while the work is shaped, not when it is finished.

Where to start next week

You don’t need to reorganise the team to begin. Pick one upcoming feature that touches something users care about and try three things:

1. Invite a QA engineer to refinement and have them write the acceptance criteria together with the developer.

2. Add “automated checks for the critical path” to the definition of done for that feature.

3. After release, look at the defects that appeared and ask whether any of them could have been caught in that first conversation.

If the answer is yes — and it usually is — you have your case for doing the same on the next feature. These practices only last when the in-house team can keep running them without outside help, so it pays to start small and make them routine rather than launch a programme.