Doing shift-left right: Start thinking and learning early in the development cycle

Teams love repeating the line: "Testing isn’t a phase." They say it in meetings and retros and feel good about it. Some even invite testers to ceremonies earlier than before.

But most teams stop there. Sprints still end with late-night testing, rushed bug fixes, and surprise issues discovered just as the release window closes. This is because shifting testing earlier in the development cycle, on its own, does not make a team faster.

It works only if your team understands one thing. Speed comes from the quality and volume of feedback, not from when or how early the tester starts active testing in the sprint. Throughout the article, I’ll use the term "feedback density". Think of it as the amount of useful learning a team produces over a given period. Higher feedback density means assumptions are challenged sooner, risk becomes visible early, and less time is spent building the wrong thing. 

Most teams shift left in clock and calendar time. That is where things fail quietly. As a result, very few teams shift left in influence. This means changing decisions before the code is written. True shifting left is asking a question during a design review, like “Is a configurable option needed at all? Then, pointing out that the new feature depends on three other services or suggesting changes to acceptance criteria that include real failure scenarios rather than only happy paths.

Moving testing earlier only matters if it increases the density of feedback. Just moving the testing activities to the start of the development cycle adds non-required activities, such as too many discussions. The goal here is to create useful feedback while decisions are still cheap to change. 

Shifting testing activity "left" doesn't count if your team isn't learning anything

Early testing is not “involve test sooner.” It is not “start test case writing on day one.” It is not “let’s move the test column left on the Jira board.”

If a lot of what testers do is validating bug fixes, but they're doing it earlier in the schedule, you have created mere decorative inclusion. Testing activity appears to be "earlier," but learning still arrives late.

Common patterns that pretend to be early testing:

• Testers attend sprint planning, but not the design conversations where trade-offs are made.
• Test cases are written early, but then they are rewritten every time the design changes.
• Developers still view “testing done” as the final checkbox before deployment.

If these patterns sound familiar, you probably moved testing left on the sprint, but you did not move it upstream in thinking. The result is early activity but late learning. These practices don’t increase feedback density. They simply move existing work to an earlier point while the feedback still arrives too late to influence decisions.

What "testing early" actually means when it's done right

Testing early is not about finding bugs sooner. It is about increasing feedback density so that learning happens while the product is still taking shape. This is what makes things faster, and that only happens when three things change:

1. From checking requirements to challenging assumptions

True early testing is not limited to asking questions like “Does this submit button work?" It includes questions like “Why do we need this flow in the first place?” and “What assumptions are baked in that will collapse later?”

For example, a tester once asked whether a configurable option needed to be configurable at all. That single question removed a sub-feature, three potential edge cases, and an entire set of validation rules. No automated test could have done that. Only early questioning could.

Queries like these, the kind that result in changes that eliminate bugs before they are coded, are at the heart of true early testing. You stop the wrong thing from being built before you ever test the right thing. Every assumption challenged before implementation increases feedback density. Instead of learning after deployment that a feature was unnecessary, the team learns before writing the code.

2. From designing user scenarios to insight into systems

Most bugs in modern products are not where you expect them to be. Instead, they live in the interactions between components, states, and data flows.

In early testing, you might map how a new feature interacts with existing ones. You might identify hidden dependencies. You might ask what happens when two asynchronous processes collide. And you would see the shape of the whole system before its code is written.

Every system insight gained at this stage can prevent a future integration bug. That insight arrives when architecture, API and workflows are still flexible to accommodate changes. At this point, problems received during testing are addressed, and the team receives richer feedback during design.

3. From filing tickets to thinking deeply about the product

Stories can pass acceptance criteria and still fail the user's experience.

A team once delivered a release where every story passed testing. But when users tried the full flow, they abandoned it because two separate stories whose tests always ran "green" produced a broken journey when they were connected.

The stories were OK. But together they made the product wrong. That kind of problem doesn’t show up inside individual tickets. It shows up when you look at the intent of the whole journey. True early testing, not Jira tickets, validates intent. In early testing, you might map the full journey across stories and notice that the login and payment flows work, but the user cannot move from one to the other. Or you might add scenarios for gateway timeouts to an acceptance criterion that says only “payment succeeds”. Or you might flag that a story marked “done” leaves the user stranded, because the next step in the journey does not exist yet.

Looking over the tickets increases feedback density because feedback reflects the product experience rather than isolated features. Teams learn about broken journeys while they are still inexpensive to fix.

The hidden success metric of your shift-left effort: Density of feedback 

Most teams measure speed. Few measure how smart their speed is. Let’s go back to the earlier examples. Removing an unnecessary configuration option, identifying hidden service dependencies or spotting a broken user journey before implementation all have one thing in common. None of them found bugs. Instead, they increased the amount of useful learning before expensive decisions became difficult to change. This is how feedback density is supposed to work.

It is the amount of useful learning you produce per unit of time.

Low feedback density looks like this:

• You find issues every few days
• Feedback loops require handoffs
• Developers switch context before getting clarity

High feedback density is different:

• Signals arrive continuously across design, development, and testing
• Developers gain clarity within hours
• Each day of work is better informed than the previous one

Example:

• Team A writes code on Monday and gets clarity on Thursday.
• Team B discusses the solution and gains context and clarity before writing code.

Team B is not faster at running tests. They are faster at learning. They ask clarifying questions during refinement, walk developers through flows that can fail while the code is still being written, and review designs before implementation locks the team into expensive changes later on.

Tips for effective "early testing" 

Early testing becomes meaningful only when it increases feedback density. Each practice below shortens the time between making a decision and learning whether it was the right one.

Embed testers in the design conversations

Testers are not simple note-takers. They are risk translators. This often sounds like questions such as:

• What happens when this dependency is slow or times out?
• What happens if the expected data is missing or malformed?
• What happens if the user submits a form twice?
• What happens when two services process the same event together?
• If this fails in production, how will we know and debug it?

A simple question during design, such as “What happens when the network drops in the middle of this flow?”, can change architecture, API behaviour, error handling and UI states before anyone pushes code to a feature branch. Every design-related question asked before implementation increases feedback density because the team learns while changes are still inexpensive. 

Use test automation for confidence, not coverage

Test coverage percentages do not guarantee insight. CI pipelines can easily become comfort blankets.

Ask:

• Which tests give real confidence
• Which tests validate only the happy path
• Which tests block progress without providing new learning

Optimise for confidence per minute, not just lines of code covered. Good automation increases feedback density by quickly giving the team confidence, rather than simply producing more test results.

Pair developers and testers around critical flows

Pick one high-risk area every sprint. Grab a developer (or tester if you're a developer) and spend 20 minutes walking through the behaviour together. Not the code. The behaviour.

This exercise uncovers misalignment faster than any document or process. Teams avoid pairing because they believe they do not have time. But pairing is what gives you MORE time to build a great product. I have seen pairing increase feedback density by quickly giving teams confidence, rather than simply producing more test results.

Collaborate beyond the testing team

Early learning comes when teams work together. Designers surface UX, developers expose technical constraints, product managers talk about business trade-offs, and that’s where you learn where things really have to stand. Each perspective increases feedback density because the team receives richer feedback before implementation is locked in.

The goal now isn’t for the tester to own quality. It’s for everyone involved in building the product to contribute. 

Close the window of uncertainty early

The gap between writing code and knowing it works can act as an uncertainty tax. Shrink that gap. Use faster test feedback with techniques such as feature flags, early observability, tighter integration test cycles, and light sandbox environments for pre-merge flows. Your goal is not simply to reduce testing time. It is to reduce the time you have to wait for clarity. The shorter is the gap between action and feedback related to it, the better that feedback becomes because you see it in isolation when it’s being built. It slowly takes the impact of the whole system. 

What to measure if you want real insight into code quality

Velocity, bug counts, and code coverage tell you nothing about how well your team learns. There are many better options available to give insights into code quality through increased feedback density. 

Measure these instead:

• Time to clarity: How long is the period between writing a feature and knowing it behaves as expected?
• Decision latency: How long does the team take to decide whether to ship, pause, or roll back?
• Defect recursion rate: How often do fixes introduce new problems? (That’s the clearest signal of weak feedback loops.)

These metrics reveal whether your testing process is teaching your team or just recording its mistakes. For example, if fixes regularly introduce new bugs, it signals that the team's feedback loops are weak or that feedback arrives too late in the cycle. This would increase the “time to clarity” measure. This is a signal to move the testing conversation earlier in the cycle.

To sum up

When teams say testing slows them down, they usually mean that learning takes time. But learning later is always more expensive. Bugs found late in the process, rework, and risky late-night fixes to production.

Testing early is not only about catching bugs earlier. It is about avoiding decisions made without enough information. Getting that information involves the whole team, and testers can be the catalyst that brings them all together. 

Fast teams are not magically fast. They learn earlier, correct earlier, and course-adjust earlier. Speed comes from clarity, not effort.

What you can do this week

If you want earlier learning, you don’t need a new framework. Start small.

• Sit in on one refinement or design conversation and ask a risk question. What happens if this dependency slows down or fails?
• Pair with a developer on a high-risk feature and walk through the behaviour before the code is considered done.
• Review a feature before implementation and list the assumptions hiding inside the acceptance criteria. Pro tip: Find three ways this feature might break, write them up, and give your findings to the developer.
• Add one observability or diagnosability consideration to a feature: if this fails in production, how will we know?

You don’t need to do all of these. Start with one. The goal is simple. Make shift-left work by focusing on feedback density, not moving testing earlier and by identifying early learning opportunities. Create better feedback sooner, shorten the time between action and learning, and help your team make better decisions before the code reaches production.

What do you think?

Got comments or thoughts? Share them in the comments box below. If you like, use the ideas below as starting points for reflection and discussion.

• What changed when you tried shifting testing earlier, and what did not change?
• How are you measuring the usefulness of your testing feedback?
• When did you last catch something major before development even started?

For more information

• Shift Left or Shift Right? Why Not Both!, Arlémi Turpault
• How (Not) To Measure Quality, Michael Kutz
• Test Automation: Always The Approach Of First Resort?, Eduardo Fischer dos Santos
• How Testers Can Help Build Scalable Products: A Shift-Left Approach, Hanisha Arora