I had one of those meditative weekends, where between solving Advent of Code challenges, seeing the new Star Wars movie, and cleaning my home office, some ideas (sort of) merged in my head.
One part of the recipe was yet-another-discussion on twitter over the weekend (over) reacting to the Test is Dead theme that came out of a few conferences several years ago. For me, I knew what that phrase meant before I saw the content – it means that how software is tested is changing. While I’m fully onboard with the changes, the talk of test is dead, and the role changing causes a large amount of fear, uncertainty, and doubt (FUD) among a lot of testers in the industry who haven’t seen how these changes can improve software quality, and how they can adapt their skills to a new world.
While in my office (during a conscious retreat from the world of twitter), I noticed my copy of Crossing the Chasm, the Geoffrey Moore book with a lengthy dissertation on how people adopt new technology. A quick fact check tells me that this curve, is called Diffusion of Innovation, and was actually first proposed in 1962.
For anyone who has somehow missed seeing this curve explained before, it’s an explanation of how people adopt a new technology; broken down into innovators and early adopters who jump in early (Moore refers to these as Tech Enthusiasts and Visionaries respectively, and as “The Early Market” as a whole). The Early Majority (Pragmatists), the Late Majority (Conservatives), and the Laggards (Skeptics) make up the Mainstream market of a technology.
While I have a vision for how test and quality specialists (described in AB Testing as “Modern Testing”), I also realize that the role of testing is in different levels of maturity across the industry. Modern Testing (which I see largely as an evolution of Agile Testing as described by Crispin and Gregory) is absolutely happening in many companies – but it’s in the Innovator’s part of the curve.
If I squint and look at the curve as “waves” of testing approaches, Agile Testing is farther along the curve, followed by separate teams of (largely) SDETS, separate (or outsourced) Test teams, and finally, low (or lower) skill teams of manual testers testing quality into a product.
The percentages are (obviously) made up, but based on biased and anecdotal information, I think the graphic makes at least a little bit of sense. There will always be shitty testing (far right side of graphic). There’s a large area in the middle that is an area largely (IMO) in transition. Armies of SDETs came and went while I was at msft – and while I still think Microsoft handled both the transitions to and from SDETs horribly, a world of testers as programmers focusing on automation is the norm for many teams.
As hinted above, with change and transition comes fear. The “manual” tester fears a world where they may need to learn automation. The automation engineer fears a world where they may write diagnostics or utilities (or, gasp, production code) instead of automation, and dedicated testers of any kind may fear a world where their work is owned by developers (or computers). As a result, many folks dig in their heels, refuse change, and all but flat out deny that test (and in general, the way teams around the world are making and shipping quality software) is changing.
Instead of yelling, “It won’t work”, I encourage these folks to ask, “How will it work”. Instead of worrying, “Will I have a job”, ask, “How can I help make these changes happen”, or even, “What could my role be in this new world”.
My thinking on the subject is as far away as it can be from worrying if I have a job in the future. I’ve said many times (to listeners, readers, managers, and co-workers), my goal is to make my job obsolete. I’m trying to make my job disappear. Not because I don’t like it (I love it), and not because I’m incapable, bored, fearful or ignorant. I want to build software teams that intuitively know how to efficiently create quality software that excites customers. In the short term, I and my team have skills and knowledge that can help in that goal – but in my opinion, if I don’t remove the need for me in that process, I’m not effectively leading my team and the feature teams we work with.
Embrace change, not fear.