A memory popped up today. Thirteen years ago I was in Las Vegas at HP Discover 2013, presenting on testing in the cloud and moving to a service model.
The talk I gave was built around one question: how do you get to market faster without compromising quality? In 2013, the answer involved service virtualisation, on-demand environment provisioning, and shifting to a testing-as-a-service model. It was genuinely new thinking at the time, and not everyone in the room was comfortable with it.
During the Q&A someone asked what I thought the next five or ten years looked like for the profession. I said upfront it was probably going to be an unpopular answer.
My view was that software testing was going to change in a way most people in that room were not ready to hear. Test automation was already becoming the norm, but this was something more fundamental. Software development itself was going to shift, and that shift would mean that we had to expand how we think about quality. What would “good” mean in the future?
If you have ever talked to me in person about this, you will have surely heard me say that “verification testing proves you built what you said you were going to build, but validation testing proves you built the right thing.”
That matters, because automation (even pre-AI automation) focuses on verification testing. That’s, honestly, the easy bit. The harder and more valuable question is whether you built the right thing. That requires a fundamentally different kind of thinking that is anchored on “intent”.
In that room, I said that I believe we were closer than most people assumed to a world where developers could readily test their own code, and where self-healing capability would be built directly into the development process. A couple of people in that room thought I had lost the plot. I recall several chuckles as well.
Thirteen years later, here we are. AI-assisted development is mainstream. If you are working with a capable code model today, you can instruct it to test, iterate, and correct its own output as part of the build. That is not a future state. It is just how some teams are working right now.
So what does the next ten years look like?
I spend a lot of time gazing into my crystal ball these days, but it is less clear to me right now what 2036 will look like, than what I thought 2023 would. The broad direction is visible. Execution is increasingly automated, and the human role is moving toward intent, judgment, and the clarity to define what you are actually trying to achieve. But the specifics are genuinely open, and anyone claiming otherwise is doing more guessing than predicting. Part of that is because of where we are on the technology S-curve that I spoke about in a previous post… once we shift into a period “dominant design” I trust that my crystal ball will clear up.
In the meantime, I keep coming back to is that the people who navigated previous shifts well were not the ones who had everything mapped out in advance. They were the ones who had built strong enough foundations that they could move toward change rather than brace against it. They approached what was coming with curiosity rather than anxiety, and explored the possibilities from a position of stability rather than fear.
That curiosity matters. Chasing what interests you, asking what a new tool or approach actually makes possible, turning it over and looking at it from all sides, weighing what it opens up against what it changes, working out whether it is something you can build on and develop something genuinely useful from. That kind of engaged, questioning approach is not a distraction from good work. It is how good work has always moved forward.
Technology will keep shifting. It always has. The question worth sitting with whether you are curious enough to go and tinker with things to see where it can take you?
If you would like to think through what this means for your organisation, I offer a free initial consultation. Book a time here.