Predictions and other stupid things

Between my talk at the online testing conference, and in discussions with Brent on AB Testing – and my day job thinking about service quality at Unity, I’ve spent a bunch of time lately pondering the role of the tester in modern software engineering, and what it means for today’s crowd of software testers.

Years ago, I gave a few presentations on the Future of Test. In hindsight, it was stupid of me to attempt to predict the future of testing, and I caution anyone thinking of going down this path (my hypocritical predictions are below). Years ago, I talked about “cutting edge” test ideas and claimed they were (or may be) the future, but few of those ideas are as interesting today as they were then. Today, I read an article on the Future of Testing that describes testing and software development practices from years ago. The future, it seems, is based a lot on context and point of view. That’s ok, and I ask  you to consider that before you disagree (or agree) with my own thoughts.

All that said, I think I can make a few claims about where testing is going – even if these changes are years (or decades) out for many testers. Consider these wild-assed guesses based on my own experience rather than predictions about the future.

1) Independent test teams are diminishing in favor of the test specialist. Many examples of this already in software. This ultimately means fewer testers, but good testers will remain in high demand.

2) The industry infatuation with automation – especially UI automation will finally fade. I’ve been asking testers to stop writing automation for nearly a decade, and I’m beginning to see more and more examples of teams halting their UI automation efforts, and investing in unit and integration tests (and monitoring) more significantly.

3) Testers writing automation will become a rarity. Hand in hand with both points above, testers won’t write that much application automation. Unit and integration tests will be written by the developers on the team (w/ coaching from the test specialist on their team as needed). The test expert on the team who code will more likely write diagnostic tools, frameworks for “ilities” (perf, security / fuzzing, stress, etc.) – as well as other tools / processes / approaches that accelerate the achievement of shippable quality.

4) Huge amounts of testing will be done via monitoring real customer usage. I shouldn’t include this one, because it’s already true for many, many products already, but I see enough people disbelieve in this approach for their product, that I’m throwing it out here anyway. Given that it’s been 10 years since Keyes said that good monitoring is indistinguishable from testing, the disclaimer makes me feel icky, but still seems necessary.

I can’t wait to revisit this post in five years and see how irrelevant my claims are.