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.
Do it. Prove that these teams are so good it’s really progress. It’s not the change that is scary. It’s the cases where there is clearly a man behind the curtain we are all supposed to ignore where it’s tiresome. Let’s talk about how you know the developers are ready. Not just that we all should assume they all will be & are.
Nice post! Do you think people fear change now because not allot of people talk about what the outcome looks like? So many people have spoken or blogged about testing being dead, but not many must or what the change could look like for testers and testing.
This has caused problems with orgs which I think further causes more fear, e.g. I’ve seen companies see a “testing is dead” message, then they’ve fired all their testers and tried to get the devs to automate all the things…
Perhaps that’s also caused by a wider misunderstanding of what testing is, and a lack of knowledge about investigation and exploration. This makes me think that perhaps the fear relates to many things, not just change… And maybe it’s justified on the basis of these other misconception s that their orgs might have… But maybe the lack of teaching their orgs is the testers main problem so the change needs to happen anyway, for the org to be able to learn.
Any way, great post! Very thought provoking. ?
Picking up Dan’s comments; in my last role, we were very much on the right-hand side of your graph, for historical reasons. As a team, both devs and testers wanted us to shift left up the curve; but the company had different ideas. As far as the company’s owners – not even the Board, but the owners above them – were concerned, testing was exactly where it belonged, down at the sh*tty end of the curve.
Their answer? Stop doing in-house development or testing and buy in all the products the company needed. Better still, buy the company that made the products.
The day after my redundancy took effect, the company moved to new offices and posted to social media: “Our new offices in the city centre are open for business! Click here for a virtual tour!”. Guess what? The link didn’t work. I took a certain amount of pleasure in posting back “You’d think they’d test this before publishing. Oh, I forgot – they SACKED all their testers!”
Well, it made me feel better.
In short, it’s not only about the tech teams and their managers. Sometimes, it’s about the whole company as well.