Book reflection: Tacit and Explicit Knowledge Rikard Edgren
Harry Collins’ Tacit and Explicit Knowledge is a book about scripted and exploratory testing. Explicit knowledge is what can be told and is able to transfer knowledge. Tacit knowledge is what can’t be told (yet), knowledge transferred in other ways than reading/listening. There is nothing strange or mystical about this, “experience goes along with having tacit knowledge”.
The notion of explicit knowledge is pretty new, it is the tacit that is normal life in society. So when traditional test techniques came around, they put our industry’s focus on the explicit knowledge, and ignored the tacit. Scripted test cases may pass on some of the explicit knowledge, but never the tacit.
For a while, exploratory testing was seen as something odd, when it in fact is the test cases that are unnatural. Exploratory testing handles tacit knowledge, but while we can give hints and explain testing, we can’t say how it is really happening. It is a collective tacit knowledge – learning to adopt to context – and to get good at it, the best way could be socializing, or “hanging around”, with those who have learnt how to do it. The transfer of this tacit knowledge involves direct contact, which matches my experiences of individual feedback being crucial when teaching testing.
Collins also explains polimorphic (complex actions in context) and mimeomorphic (specific things), which could be used to expand on manual and programmed (automatic) testing.
The concept of Mismatched Saliences feels important for testing missions and test strategy; different parties don’t know that the other ones aren’t aware of a crucial fact.
This is my take on the three kinds of tacit knowledge for software testing:
Relational Tacit Knowledge – unspoken things handled by conversations
Somatic Tacit Knowledge – test execution
Collective Tacit Knowledge – test strategy
Relational can be made explicit if we put the effort into it, somatic deals with limits of our bodies and minds, collective is the strongest, and cannot be explicated. Blindly following requirements is an example of explicit knowledge taking overhand. But by working with requirements – asking questions to people – we can get to the collective tacit knowledge, to understand what’s really important. When you do this, you’ll see a lot more, whatever you are testing (serendipity!)
It’s not a one-bite book, but for me it was perfect, probably because I like philosophy, teach a lot, and currently research test strategy. Surprised though that there were more than a dozen typos.
A proof of a really good book is that it sticks, that it pops up now and then and help you. This has happened to me several times in the last months: I realized weaknesses in a knowledge transfer document I wrote (no tacit there!), I have tweaked teaching exercises so they have even more interaction, and my (and Emilsson’s) evergoing quest – how to become an excellent tester – has gotten more fuel. I think it is an important book, and I find it more than cool that professor Collins is coming to Göteborg for EuroSTAR testing conference.
I suspect it is tacit knowledge to apply this book to testing, so if you’re interested, you need to read for yourself and discuss with others about what it means to you.