Testing Doesn’t Just Happen at the End
I was at Agile Testing Days in 2025 and I lost count of the conversations that went the same way. People wanting a seat at the table, people wanting to shift left, everyone clearly knowing the theory inside out… then you ask what their week actually looks like and it’s testing after development, on their own, waiting for somebody to finish something. Years of us all talking about testing earlier and there’s still a phase at the end with a tester sat in it.
The idea that testing happens at the end of building something is still hugely prevalent. After all, we need to have something to test right? Well yes, we need something but that DOESN’T NEED TO BE A FINISHED PRODUCT.
I’ve worked in teams where that was the literal process; testing happened in a dedicated testing week and every bit of it was manual. Everything sat there dev complete and untested until that week came round, a bit like a big pile of birthday presents nobody’s allowed to open yet (except when you finally do open them they’re all broken and somehow that’s your fault). Nobody thought it was strange, it was just where testing lived!
To speed up delivery (super useful in Agile environments) we need ways to shorten how long it takes to get feedback and fix things. That’s why we don’t have to just test a finished product at the end but instead can test earlier by testing CODE, DESIGNS AND EVEN IDEAS.
Assumptions and Bad Foundations
So this is the most shift left we can get… testing the initial idea for a product or feature. You might say “But Callum, why would we want to test ideas?” Well that’s because humans are fallible and have biases which leads to uncertainty in what we might be asking for. People might assume knowledge, or assume something’s a good idea to do… both of these things lead to risk; of building something wrong based on poor knowledge or just building the wrong thing because the idea was bad.
The Chair Example
This is something that’s used a lot in testing. Imagine that a product owner has asked for a chair, well we can test that idea by asking questions and teasing out knowledge.
- How many people want to be able to sit down at once?
- How long will they be sitting for?
- Is this for social interaction, work, eating?
- Do they actually want to be able to lie down too?
Instead of a chair, do they actually want a sofa bed?
By testing the ideas early, we’ve saved a lot of time in building the wrong thing and can start working on what’s actually needed.
But look at what we’re really doing there, we’re doing risk analysis before there’s anything to run a traditional test against. We’re finding out what could go wrong and letting that tell us what’s worth our attention, which is a habit worth building and something I’ve written more about in starting with the risks rather than the method. I’ve also built a Triforce skill for this if you fancy getting AI to help you do it in a pipeline.
Designs, code and the non-functional stuff
Okay so as well as ideas, what about designs and architectural thinking for software? This is where we can start raising the risks on things like maintainability, performance, security, usability, accessibility and all those other awesome non-functional things. These need to be DESIGNED FOR AND BAKED INTO YOUR CODE AND SOFTWARE because it’s really hard (or impossible) to retrofit them in after something’s been fully built. If we don’t test the designs and then use the outputs of that testing to inform building for these things we’ll end up with flaky foundations for our product. In fact, by testing them at the end of a project and only finding issues late in the game you have to ask yourself “AM I HAPPY TO HAVE TO REBUILD THIS WHOLE THING AGAIN?” (the answer is usually always no).
Never done any of this before? You don’t have to invent the practice from scratch; there’s a live shift left demo where I work through a story and a session with Marie Drake on baking quality thinking into story shaping too.
Your pipeline won’t tolerate a test phase
Here’s the bit that makes this urgent rather than just nice practice. Engineering teams want to ship fast and in an automated way, not be held back by manual testing phases that hold up everything (although sometimes manual testing is needed, see my testing week above). A dedicated manual test phase stops an automated pipeline dead, and nobody wants that, so the pipeline itself is quietly asking you to stop thinking in phases.
That means testing has to happen in more places than the one you’ve been standing in. Fast unit and API level checks on every commit because they’re cheap and they tell you about quality quickly, a deliberately small set of end to end journeys because you probably don’t need as many of those as you think, plus your accessibility and security scanning running continuously rather than once in a panic before a release. None of this is new by the way, I was talking about why continuous testing has to be embedded into pipelines back in 2020 in Testing in the DevOps World!
So what can I do?
TESTERS
Keep fighting the good fight, socialise and educate your team mates on how testing earlier can help your teams. Run Triforce and risk analysis sessions to call out issues as early as possible and get testing earlier, headlessly via APIs if you can.
Product owners / managers
Understand how quality can be baked in early and get testers into your teams as early as possible to help you; testers are valuable from inception of a project after all. Make sure time is given to testing throughout the software delivery lifecycle and set up sessions like Triforce to help engage with testers and give them a seat at the table.
DEVELOPERS
Make things testable as early as possible and engage with risk reviews or quality conversations that testers may want to have. Remember that baking a fix in early is better than having to raise a defect and fix it later. Implement tooling to benchmark for non-functional elements like performance and security oh and WRITE UNIT TESTS AS YOU GO.
RECRUITERS
Understand that shifting testing earlier is a specific skillset in itself and may require exploratory testing. Evangelise to organisations (especially start ups) how this type of testing is important in environments of fast paced development and uncertainty. Work with organisations to understand the problem space of testing and how a tester could help them to shift left / right and create a job spec accordingly (I’ve written about what to look for in a senior tester if that’s useful).
One last thing about that “end”
Something struck me at ATD. Everyone was talking about breaking out of their testing phase silo by shifting left, getting a seat at the table earlier, all of it good stuff… nobody mentioned shifting right. Not once.
Which is a shame, because you’ve assumed the wrong end in “testing comes at the end”. Deployment isn’t where testing stops, it’s where all the lovely juicy actual user information starts turning up, from real people using the thing you built rather than from a staging environment full of made up data. Think of it like play testing a game; you can balance your combat or write out the best riddles all on paper but you don’t really know what players will do until they start getting involved (usually something I didn’t designed for *sighs in Dungeon Master*). If that’s got you curious then I’ve written about why aren’t we talking about shift right at proper length.
Prevention is better than cure! We need to step out of silos and test earlier than “at the end” to stop issues from happening before they even happen.
Thanks for reading. If this resonated (or if you think that I’ve got it wrong) there’s more to read on the blog… or get in touch via LinkedIn. I’ll talk quality to anyone who wants to listen!