A short post this week, as I’m writing this in advance of taking a long weekend off to take a long walk in the woods. If you’re not subscribed to this newsletter and usually find it on LinkedIn, you will find it a few days late this week. While we’re here…
The Chasm
I’ve been thinking recently about why every time I (or anyone) brings up the notion that not all software teams need people dedicated to testing that some sort of internet battle ensues. I’m reminded of the very first time I talked about the Modern Testing Principles in public (and yes, these are closer to delivery principles, but Brent and I were trying to describe what we were seeing in the way teams shifted how they delivered software. In that presentation, I showed this graphic from Crossing the Chasm
The author (Geoffrey Moore) uses a variation of the innovation diffusion curve to make a point that with new technology, it’s a challenge to jump from early adopters to an early majority of users.
From that, I pondered and created this stellar graphic:
Please don’t beat me up for writing low-skilled traditional testers on the far right. While it’s not generally what the laggards in software are doing, it’s true enough.
But let’s go back to the Geoffrey Moore version and what that may look like in 2023 software development and Modern Testing.
Innovators - There are many organizations shipping high quality software without dedicated testers. That’s just a fact. There are organizations without dedicated testers shipping bad software too, but it doesn’t make it less of a fact.
Early Adopters - There are also a lot of teams shipping high quality software with very few testers - often someone in a “Quality Coach” role, or someone who has expertise in testing that is used across several teams. I see this a lot.
Early Majority - In my mental model, these are folks working in a somewhat Agile environment, but like having the safety net of testers to find the difficult issues. Nothing wrong with that, that’s just where they are.
Late Majority and Laggards - I made software this way in 1999 - it was fun. Then.
Jump?
I’ve spent the last 10-15 years of my career living with the Innovators and Early adopters (as far as software delivery goes), but I spend enough time outside my bubble to know that many, many teams still have dedicated testers, and do just fine.
But still - when I bring up the topic, it causes mayhem. “Nope - that’s stupid, and you know nothing about testing” is a pretty common comment. And what I tell those people (and I’m telling you now) is to put on your context hat, and change that statement to, “Nope - that is stupid for my context, and won’t work in my context” - because that’s really the only fair statement you can mane - just as it’s really only fair for me to say, “in most contexts I’ve worked in for the last decade, dedicated testers weren’t needed”.
Both of those are fair statements.
Uh-oh
I got a little on a soap-box there, but hopefully not enough to cue a flood of replies. All I really want to ask is this:
If you find something you don’t agree with - it can be about software delivery, testing, or succulent flowers. Ask yourself - “can this statement be true in other contexts?”. I don’t feel like that happens enough, and I think it blocks team (and personal) maturity.
Just don’t be afraid to jump the damn chasm.
I’m currently in the middle of nowhere - replies will be delayed.
-A
I hope the middle of nowhere treated you well. Solid post. It got me thinking about maturity models but flipped around the other way. I have a similar concept to how beta testing is done. It's been around for a long time, but it's still managed as if we were back in '95. Thanks for the read, Alan!