Testing Antipattern: Non-Testing Buzzwords
A sure sign that your tester isn’t a tester anymore is that they stopped talking about testing and using fuzzy self-help-sounding words such as culture, coaching, innovation, collaboration, and communication. Testers should be talking about risk, product requirements, bugs, tests, and well, testing. It is actually OK if your dedicated tester is introverted and hides in their cubicle like a hobbit as long as they are actively testing the product and writing bugs. Only the testers that don’t much like testing wander from their cubicle and pretend to be Tony Robbins.
The argument is that if these testers spend their time trying to convince the entire organization to care about quality and do their testing for them, then quality will improve overall. I’ve yet to see this work in practice. Even in my time at Google, the engineering teams and product managers either cared about quality, or they didn’t. The test teams would spend much of their time not trying to ‘fix’ the teams that didn’t care about quality, we just left them to their own devices, and they suffered the consequences of poor quality. If developers don't care much about quality, it is a hiring problem, not a mentoring opportunity. We invested in the teams that did care about testing, by adding more testers, or improving their testiblity or test infrastructure and execution--not by coaching.
Testers should be maniacally focused on what they do best--assess and mitigate system risk. This is their specialty, and if they do it well, the product will be high-quality. I’m not sure why experienced testers decided they should be self-help coaches, but it is highly correlated to the time that testers lost their identity in the transition to agile and continuous delivery in recent years.
Even agile and continuous teams need testing, not coaching. The trick to deal with this is to simply hire great dedicated testers, keep them in the loop on all the sprint work, but let them work independently of the sprints and focus on global risk. This might mean that the sprint team is changing an icon in the app this week--but it doesn’t mean that should be the focus of the tester that week. The tester should be focused on the larger picture of technical debt and risk and working to mitigate that as much as possible.
If testers aren’t talking about anything but testing, it is a problem whose solution is also probably a hiring one.
--Jason Arbon
"If developers don't care much about quality, it is a hiring problem, not a mentoring opportunity."... so true
One other cautionary bit: "If testers aren’t talking about anything but testing,...." Yes ..... but there needs to be recognition that "testing" is a very broad subject. A lot of people seriously undermine testing by not recognizing that it is a social discipline with a technical context. That social discipline means you can be talking about testing and yet someone may not think you are. For example, testers are good at categories of error and the theory of error. This is all about how humans think fallaciously or make cognitive mistakes when they engage with complex things. Sometimes when you talk about that stuff, someone might think you're no longer talking about testing. But, in fact, you are engaging with one of the most important parts of it.
This part: "I’m not sure why experienced testers decided they should be self-help coaches, but it is highly correlated to the time that testers lost their identity in the transition to agile and continuous delivery in recent years." YES! Absolutely correct. There's more to it than that but I entirely agree that an edge has been lost around testers actually engaging with the discipline of testing. (This is somewhat of what I was talking about here: http://testerstories.com/2019/04/do-testers-understand-testing/.) The only slight reframing I would suggest is not a focus on "dedicated testers." Rather, it's on test specialists. Which, ultimately, I believe is a role that has to a type of developer. It's a developer with a test specialty, as opposed to a programmatic specialty or even a code specialty. (Although I argue test specialists do have to have a certain facility with coding or, at least, code.)