I recently read a blog by Michael Bolton ( http://www.developsense.com/blog/2011/12/shapes-of-actions/ ) that recommended the book "Tacit and Explicit Knowledge" by Harry Collins. In his blog, Michael emphasised the differences between what Harry Collins described as "mimeomorphic" (shallow, mechanical) and "polymorphic" (intuition-based) actions. The book, however, provides a wealth of information that goes far in describing the depth of impact to the software testing profession. Here are a few key items that I gleaned from the book. (Thanks to Phil Kirkham for prompting me to write about this.)
It took me quite a while to absorb the book. In many cases, I had to re-read some pages and sections more than once to understand what the author was saying. However, I think the effort was worth it. I would like for others to support the author and buy this book - I would be interested in comments and different views on it.
In the following, plain text will indicate my understanding of what the author was attempting to convey. Anything that is based on my own background and experience I have placed in square brackets .
This book is interesting in that the author attempts to categorise various aspects of knowledge transfer into discreet categories. These categorisations appear to be very well thought out, with background information to develop a strong foundation for the development of the categories. Note that the term "string" generally refers to the things that convey the message and "entities" generally refer to the targets of the transfer.
Special note: the author has a very good dissertation in the book on the word "cannot", which can range in meaning from a philosophical impossibility to a simple "secret" kept within an inner group. I use the word a little more carelessly in this article!
- The emphasis in the book is on knowledge transfer, specifically the impact of the message on entities. [The primary distinction for testing is the difference between inscription and interpretation.] An example of inscription is the rote memorisation of the ABC's or the times tables and is performed through repetition. Interpretation is the extraction of meaning based on the context of the message. [This has a direct bearing on the difference between scripted tests (inscription) and exploratory testing (interpretation).]
- [Testing essentially boils down to communication.] Whether a communication takes place depends solely on the outcome (i.e. impact on the entities). Communication occurs when the entity is able to jump the gap in the understanding of a limited string in the presence of tacit knowledge. The author lists five factors that enable communication to occur listed as "conditions". [The primary limitation in creating explicit (scripted) tests is condition 5, which is the requirement for fluency in the language. This fluency requires a knowledge of the social context in which the action is to be performed, which is nearly impossible to convey strictly through scripted procedures.]
- The author goes to great pains to make a distinction between information and meaning (which he refers to as the "Transformational-Transitional Distinction"). In essence the transfer of information can be done lossless through error correction, but translation is never lossless. However, the loss can be mitigated by making the string longer (e.g. procedures). [The two types of test approaches (scripted and exploratory) cannot be mixed - the perfect running of an automated (or manual) script can only be done through meaninglessness (i.e. pure information transfer)! The human running the exploratory test must be malleable - open to adjustments as the society and language change.]
- [I was particularly interested in the author's distinction between inscription and learning. With repetition, a tester can gain a great amount of familiarity with an application. That should not be mistaken for understanding of the product under test!]
- The core of the book is the three areas of tacit knowledge that are defined: relational, somatic, and collective. [Understanding these types of tacit knowledge is key to performing software testing. Most discussions on using automation, scripting, and written procedures deal with the simplest case of relational tacit knowledge. Addressing software quality using approaches such as context-driven development require an understanding of the impact of of the other two types (somatic and collective).]
Reading this book will probably have as big an impact on you as it did on me. It is a deep well of which I have only begun to plumb the depths.