The Ghost of Tests Yet to Come…
Forgive me – if I’m asked to write an article about the future of testing just before Christmas, then I obviously think of “A Christmas Carol”. Since I’ve misplaced my crystal ball anyway, it might make sense to see what the ghosts of testing past and present tell us about what we can expect.
What do we know?
Somewhere, a test is failing. If there’s one thing that ten years of testing has taught me, it is that it’s sometimes difficult to know what we’re expecting when testing. And when we do have a pretty clear idea of our expectations, then testing often shows us that there is a gap between our expectations and an implementation or behavior. We can see the gap due to a failing automated test in an area of the software that “definitely isn’t affected by these changes”, or we might see it by finding a new risk that we discover by exploring around a new feature. I doubt that these aspects of testing are going to change in the future. Nevertheless, the contexts and ways that we apply testing are definitely changing. I see three main areas:
New technological contexts
No article about the future would be complete without a list of the current hype topics – Internet of Things, Microservices and Industry 4.0. Before you shout “bingo” though, these subjects are highly relevant to testing. At the EclipseCon Europe conference in autumn 2016, I was asked: “How are we ever going to test the Internet of Things?”. My honest answer at the moment is a mix of “I don’t know”, “carefully!” and “using similar techniques and structures as we’ve been using for years”.
The challenges of testing IoT systems start with functional aspects – how can we test functionality across multiple protocols, networks and devices? Alongside functional testing, non-functional areas are also going to be critical. Security, efficiency and robustness against fallouts are aspects easily forgotten when testing applications – we won’t be able to allow ourselves that luxury for IoT.
The more connected we become, the more we need to think about ethicality as well. An excellent Project Quality Day 2016 talk was dedicated to ethics in software development. As software eats more and more of the world, how are we mitigating ethicality risks?
New opportunities
Maybe the news isn’t all gloomy. Over the last years, we’ve seen companies and teams moving from long release cycles and manual test phases to continuous integration, then continuous delivery, and DevOps. I attended a talk this November by a team that has reduced some of their pre-release tests and instead use much more monitoring in production. They know that their pre-release tests will find the worst problems that they can check for in advance. Monitoring in production lets them see what is actually happening in the system and react quickly.
For applications where it can be used, and where the impact of a fallout isn’t life-endangering, I’m excited about the prospect of technology that lets us monitor the system in real time. Nevertheless, I don’t see that monitoring in production means that there is no need to test continuously during development. In fact, I think the contrary: continuous testing at a well-defined level is what lets us release frequently and monitor / adapt in production in the first place. The worst knowable errors need to be caught before releasing.
The role of the tester
Which brings me to my final point. I don’t see that the role of the tester is going anywhere soon. Yes, we are automating many more things – but we can (currently) only automate what we can define. Anyone who has heard me talk about exploratory testing knows that exploration and investigation are highly important for identifying unknown risks. Just because the technological world is changing doesn’t remove this truth.
The role of the tester has been changing due to agile processes – and this is likely to continue. Testers are integrated team members and the whole team shares the responsibility for quality. Testers are growing into roles like test consultants, test coaches, test experts and also communication experts. The last point is especially relevant in my mind. As much as we might like to develop one, there is no formalized language that removes the need for discussion, questions, clarification and conversation amongst stakeholders, team members and users. We are already seeing testers working to improve team communication about quality and user expectations – and I see this trend continuing.
The mists of the future
One thing that has to happen for this to come true is that customers, IT leaders and managers need to see quality as something worth investing in. Too often we hear in projects that testing is too expensive or that we can scrimp on the testing effort. It needs to be accepted that quality (most specifically quality implemented and supported by experts in the field) is worth paying for. I think we’ll definitely get there someday, but I would prefer it to be before something awful happens. I guess that’s my ghost of Christmas yet to come – we can change our future for the better if we start to place more importance and invest more in quality now.
About the Author
