Arguing Micheal Bolton's 20 statements about testing

Michael Bolton, one of the most recognized testers worldwide (assuming we take into account the number of followers), has recently published 20 very interesting tweets on his account. This leads to a very interesting discussion, which I recommend reading too. Unfortunately, Twitter wasn’t designed for such lengthy conversations and it’s hard to grasp what’s going on there. Don’t get me wrong though, I like Twitter and you should too. It seems like most of the IT professionals use it every day and share quality stuff there.

The thing is, as much as I consider those statements valuable and interesting (hence they’re all cited here), I can’t fully agree with all of them. Twitter char limitation (140) isn’t enough to express my doubts, so let’s move the discussion to the blog world.

Edit: It seems like I may have taken Michael’s words out of context, which I hadn’t been aware of. Turns out, his views on testing are pretty much like mine. See the comments for clarification.

1. Testing’s value will never be /immediately/ clear to everyone, nor will everyone want testers as such. I believe we must accept that.

— Michael Bolton (@michaelbolton) May 12, 2016

Such a negative and disempowering statement. I had already talked about the ever-changing tester’s role these days. Yesterday I had a pleasure to listen to Micheal Feathers’ talk on Geecon titled ‘Testing patience’. I managed to capture the key slide from the talk (see below). Why would we strip ourselves from the power to redefine testers’ role in IT? It’s pretty much in our hands.

2. When we are describing testing’s value, we had better be clear on the extents and limits of what testing (and testers) can accomplish.

— Michael Bolton (@michaelbolton) May 12, 2016

Fully agree. Testers aren’t magicians and saviors. They won’t change the flawed design by night. They can however point out the problems early.

3. As a tester, I can make people aware of problems in the product of project. I do not have the authority to make them fix those problems.

— Michael Bolton (@michaelbolton) May 12, 2016

This is again a surprisingly disempowering statement. Testers should be part of the team with all the privileges and responsibilities. If production is down I don’t see why testers should not actively seek root cause and solution. Especially when they have vast experience using the system.

4. I do have the capacity to experiment, explore, infer, imagine, inform, or advise. I don’t have the power to mandate people to do things.

— Michael Bolton (@michaelbolton) May 12, 2016

Agree. Some time ago it fashionable to treat testers as quality gatekeepers. It simply didn’t work.

5. By acknowledging (4) immediately, I want to avoid this question: “We’ve got *testers*; why are there still problems in the product?”

— Michael Bolton (@michaelbolton) May 12, 2016

Classic fingerprinting problem. That’s why testers were integrated into development teams and gatekeeper concept buried. Everyone is responsible for quality.

7. I help teams to defend the value of products, discovering and alerting them to critical problems that they might not notice without me.

— Michael Bolton (@michaelbolton) May 12, 2016

Nice. I like that.

8. That (7) said, I try to maintain both epistemic and political humility. Oh-oh; weird words. Let’s unpack those.

— Michael Bolton (@michaelbolton) May 12, 2016

Yeah, sometimes it’s not easy to show problems. Especially when the teams are remote and we have additional cultural differences. That’s why books like the psychology of software testing are needed.

10. “Political humility” means acknowledging that I don’t control the code, the product scope, the project, or people. I am not Authority.

— Michael Bolton (@michaelbolton) May 12, 2016

Again, psychological stuff. Software development is a social activity with all its nuances…

11. If I believe that I exert control, pain will follow. I may annoy those who do have authority; they may ignore me and I’ll be frustrated.

— Michael Bolton (@michaelbolton) May 12, 2016

Not sure about that. It seems like an error during exerting control. In mature companies, this shouldn’t be the case.

12. I must therefore establish my role and my commitments such that others *invite* my help, rather than me inflicting help on them.

— Michael Bolton (@michaelbolton) May 12, 2016

Obvious. There is no such thing as unwelcome help.

13. Part of that, to me, requires me to acknowledge that they write the code, fix the problems, manage the project, make the decisions.

— Michael Bolton (@michaelbolton) May 12, 2016

We fix the problems. We make the decisions. Why would we distance ourselves from the problems?

14. I help them to notice problems.When they change things, they—not I—prevent those problems from turning into worse problems. I *help*.

— Michael Bolton (@michaelbolton) May 12, 2016

We change things, we prevent the problems. Testers help throughout every project phase.

15. When I acknowledge that I help them prevent problems, I empower them; I acknowledge their roles and responsibilities respectfully.

— Michael Bolton (@michaelbolton) May 12, 2016

Don’t like that. Strict role borders lead to handoff waste. We should aim at as much blurring of roles as possible in software development. That’s much more efficient.

17. To say “I help others to prevent problems” puts credit where credit is due. To say “I prevent problems” is to seize credit from people.

— Michael Bolton (@michaelbolton) May 12, 2016

We can prevent problems. Just like everyone in the project. Not sure why we would disrespect someone by doing that.

19. I can develop code, write documentation, participate in reviews, etc., etc. I’m not shirking any work here; far from it.

— Michael Bolton (@michaelbolton) May 12, 2016

Those statements seem like a contradiction to #13 and all those disempowering before. Finally, an acknowledgment that the testing role can be very broad. Fully agree.

20. If we’re talking about my testing role, I don’t commission the painting; don’t grab the brush from the artist; don’t take undue credit.

— Michael Bolton (@michaelbolton) May 12, 2016

We should take credit and responsibility just like everyone else in the company (including HR girls). Testers are no exception here.

Tags: testing thoughts, testing