Filip Lukacevic
Quality Assurance
Share article
Here's the setup I spent my first few years in. Product writes requirements, design signs off, developers build it, code review passes, and then at some point near the end a ticket shows up in my column marked ready for testing.
That's when I'd find the problem.
Sometimes it was small. A misaligned button, a validation message that said something unhelpful, whatever. Twenty minutes of someone's afternoon and it's done.
The ones that actually hurt were never like that, though. Those were the requirement nobody had really pinned down, or the user scenario that hadn't occurred to a single person in the room, or the integration that worked perfectly right up until you pointed it at a real account with real messy data in it. And by the time I'm looking at one of those, what I've got isn't a fix. It's a design conversation, a rewrite, updated tests, another round of review, and an uncomfortable message to whoever's tracking the release date.
I'd be raising a problem with a decision that got made three weeks earlier, to people who'd long since moved on to other things. Being right at that point costs everybody a fortune.
Where QA enters the lifecycle
A lot of people hear shift left and picture QA standing behind developers trying to test things that don't exist yet. It isn't that. That would be miserable for everyone involved.
It mostly just means being in the meetings where the decisions get made, and asking the questions there instead of asking them three weeks later in a bug report.
Password reset is the example I always end up using. The requirement is one sentence. Users can reset their password using their email address. Everyone nods, it goes in the sprint, nobody thinks about it again.
Put a tester in that refinement and the nodding stops fairly quickly:
What do we do if that email isn't in our system? Say so, or stay quiet? One of those leaks information about who has an account.
How long is the link good for, and what does someone see once it isn't?
Can you use the same link twice?
If someone mashes the button four times, do all four links work, or just the last one?
What about when the email takes ten minutes to arrive, which it will, at least once.
None of that needs a test environment. None of it needs the feature to exist yet. It just needs somebody in the room whose first instinct is to go looking for the edges.
Last time I went through that list in a refinement we spent maybe ten minutes on it and walked out with four acceptance criteria that hadn't been there before. I'd bet money those were four bug tickets I never had to write.
Somewhere along the way the question I'm being paid to answer shifted from "does this work?" to "what should this actually do?" The second one is a much better job.
The thing that finally made this click for me: a bug found in testing almost never starts in testing. It started somewhere much earlier. Testing is just where it becomes visible.
The usual chain goes:
Unclear requirement → wrong implementation → failed test → rework.
And shift left is really just trying to break that at the first link rather than the third:
Unclear requirement → someone asks a question → requirement gets clarified → it's built right the first time.
Nothing to report at the end of that one. Nothing to triage, nothing to retest. Which is good, and also a bit annoying, because it makes the work completely invisible. Nobody's ever sent me a thank you note for the incident that didn't happen.
This is also where my old bug count falls apart as a way of measuring anything. A high number might mean QA is sharp and catching everything. It might equally mean the team keeps introducing problems early and finding them late, sprint after sprint. On its own the number tells you almost nothing about whether anything is improving.
The timing thing gets worse the more you have on. Catch a defect the same day it was written and it's usually a five minute conversation, because the developer still has the whole thing in their head and can tell you exactly why they did it that way. Catch the same defect a month later and the two of you are doing archaeology, going through commits and dependencies trying to reconstruct a decision that neither of you remembers making.
It was never really about testing faster. It's about closing the gap between doing something and finding out whether it was right.
The timing relationship is illustrative rather than a universal cost model.
I want to be careful here, because this is where a lot of shift left advice falls over. You can't buy this. There's no tool that installs it.
I've seen teams with genuinely excellent CI pipelines who still treat testing as the thing that happens once the real work is finished. The pipeline runs, everything goes green, and the handoff underneath hasn't changed at all. What has to change is who's in the conversation, and when.
Discovery. QA is there to surface risks and awkward user scenarios while they're still cheap.
Refinement. Somebody reads the acceptance criteria properly and says when they're too vague to test against.
Development. Developers and QA talk about testability and edge cases while there's still time to change things.
Continuous testing. Unit, API, integration and exploratory work all feeding back as you go, not in one lump at the end.
Release. The team makes the call together instead of waiting for QA to say a magic word.
Automation helps a lot here and I don't want to undersell it. API, integration, smoke and regression suites running in CI/CD means you hear about breakage in minutes instead of at the end of a sprint. But the thing I actually value most about good automation isn't the coverage. It's that it hands me back the hours I'd otherwise spend clicking through the same regression checklist for the ninth time, and I get to spend those hours on exploratory testing instead. That's where I find the genuinely weird stuff, the things no script would ever have thought to try.
What you're going for is a short loop. Build, test, feedback, fix, carry on. What you're trying to get away from is building the whole feature, handing it over, discovering eleven problems at once and then spending a week unpicking them.
QA, product and development collaborate throughout the lifecycle rather than working in separate phases.
Shift left isn't about moving the QA team to the front of the process like you're shuffling furniture round a room. It's about moving the thinking there. The habit of looking for what could go wrong, applied at the point where changing the answer is still cheap.
The testers I've learned the most from don't wait around for a build. They're in refinement picking at assumptions, asking the slightly irritating question about what happens to an expired token, making requirements testable before anyone's committed to building them.
I don't keep the bug count anymore. If I'm honest the sprints I'm proudest of now are the boring ones, where the feature came out more or less as intended and my ticket numbers were unremarkable. Harder to point at in a performance review. Much better outcome for everyone else.
The best time to catch a defect is before it's a defect at all.
Share article
