The "tacit"
In the RST slack, I liked a photo posted by Adam white.
Few questions came to my mind:
- How does this apply to software testing?
- Could we name 3 rarely articulated, messy, and "purposeless" behaviors related to testing?
- Why are they lost in the quest for legibility?
- What would the community reaction to this knowledge brought to light?
- Will any tester be able to take advantage of it?
- or does it require a special background/personality/environment?
Adam's answer went like this:
"That's a great question...
In your question, you missed the "From the outside" part of the quote which is important to give context to the answer. Here are 3 "testing" skills that can sometimes be seen as purposeless. One could argue that all team members need this, but, as you pointed out, we are mainly talking about software testing here.
- Bug Investigation
- Coverage reporting and storytelling about the product, the project, and testing
- Risk identification and mitigation
These 3 are lost in the quest for legibility because they can't be summed up in a single number or word. They don't fit neatly on a dashboard and it's messy to figure them out. It takes time and we don't wind up with a pretty green bar at the end. You need brain thinking and thoughtfulness and perhaps most importantly context. These things are, oftentimes, tacit. The person who's doing the work has a feeling, an inkling, a hunch. They follow it and find the most beautiful issues ever thought of. (Bug investigation and storytelling - Ask me about the 'on the hour' bug sometimes).
This sense, this tester sense, can be taught but only to those that are willing and who are willing to try a different way. It's very Tao, Buddhist like as well as relating to the stoics. This is why certain people can predict the future as it pertains to software and why heuristics are useful. The patterns are the same from product to product. There is no magic - you just need to know where to look, what patterns keep popping up. They start to form a model in your head. "On this new product we saw an issue that was the same as the old product - I wonder if there more that are similar".
At a certain point you don't even have to refer to the heuristics anymore they become as etched into your brain as sleeping, eating, and breathing. (Risk Identification and mitigation).
The community reaction to this, (if you mean community to be the company one works for) when done appropriately, is one of astonishment that mere mortal testers can shed such a profound light on the qualities (chose that word on purpose over quality) that the product is exhibiting (or sometimes not exhibiting).
There will be a shock that testers could add such value. Developers will talk about you for years to come. Old colleagues will remember things you and your team did that you have long forgotten. I was able to take advantage of this when I played the role of tester, test lead, test manager, test director, and all roles after that. I don't think I have a special background, personality, or environment. I have a willingness to learn, to try new things, to teach what I know to others. I bring the lore of bugs from the past to the present. I do my best to explain my tacit knowledge and explain what goes on behind the curtain of software and my brain. I like to reveal the mystery behind the small cultural differences, the odd and the distinctive lifestyles (of skilled testers).
So I thought:
What if we can train experienced testers to speak/teach/share their experiences in a way that decipher them? How could we do that? I believe testers do more/differently/deeply than they tell. And I would argue that not describing the "tacit" could lead/encourage some "talkative" people to minimize expertise to mathematical formulas, "best practices", and fancy measurements. My research aims to bring this knowledge to light, so I need to sense it myself first to be able to describe it to others.
Adam replied:
"I think we need to do more talking together as testers. We need to talk more to developers, product managers, executives, and then report back the challenges and the wins! (The wins are important - sometimes we forget that).
I used to go to conferences where we could discuss ideas, hash them out, explore, debate, argue. I've also attended conferences, or workshops, where people present experience reports.
Just being a part of the RST slack community is one thing we can do. Encourage more people to take any course from @satisfice @michaelbolton or @Robert Sabourin (those are the ones I'm most familiar with).
Thankfully there's been a lot of groundwork done already:
Explaining Testing To THEM and Low-Tech Testing Dashboard"