Have you ever wondered why it does not make sense to ask or expect for complete written requirements?
Do you know why trying to write all test cases to capture the testing needed to be done will bring you to a dead end?
Sometime ago I worked on a big project. There were about 50 people involved. These people were divided into various teams. And these teams handled various products from the entire suite.
One of those products was hard to install. Imagine that simple settings that could be saved in a config file, like xml or json, were saved in windows registries. The installation of the suite in production was a ‘special’ event on its own. I use the word ‘special’ not in a good sense. Each time an install was being done; people were awake in the middle of the night to stay to test it. But this was one problem in a sea of problems.
One day, the man responsible for the product installation announced his resignation. His resignation worried me. I asked my colleagues in the office. They weren’t worried. They said, “it’s a different situation, but look, the man who is leaving also writes in a wiki. So, it will be ok”. They had the impression that all what is needed will be made explicit.
For me this did not make any sense. Not all knowledge can be made explicit. We have a lot of implicit knowledge. Harry Collins in his wonderful book named Tacit and Explicit Knowledge explains why. Imagine that knowledge can be represented like an iceberg. What is above the water is the explicit part and beneath the water the tacit part. So:
- weak or relational tacit knowledge – Is tacit because of the relationships between people that arise in a social life context. For example:
* concealed knowledge – knowledge which is kept secret intentionally;
* ostensive knowledge – knowledge which is hard to be described/comprehended. Because of that we point to a word, object or a practice to describe it;
* logistically demanding knowledge -imagine a person who knows where everything is, but would not be able to list it if asked),
* mismatched silences – knowledge kept secret without intention;
* unrecognized knowledge – a person is doing certain things in certain ways. This person would not tell another person because it might not know if these are worth to be told for the second person.
- medium or somatic tacit knowledge – is tacit because it is incorporated in the human body. How we type, how we juggle, how we balance on a bicycle. What is also important here is about the contrast between conscious and unconscious processing, just think of the process of learning/riding a bike.
- strong or collective tacit knowledge – is about the social aspects/interactions/relations people have and the knowledge that derives from this. These will influence also the social judgment of why certain things were done. The most important thing is that these things cannot be described and learned by explanation; it must be practiced in a social environment.
For me this was the decipher key of this type of situation. It was more than clear to me that even with all the goodwill, that man could not have written everything in a wiki and that things would have escaped to him. And this is ok, normal. I felt calm. I don’t know how to describe this calm; maybe it was a calm because it helped me focus on what I knew would come.
Do you wonder how the story ended? That moment I anticipated arrived, and it was a difficult moment for my colleagues in that project. So difficult that replacement also suffered enormous stress and left.
Connection with test cases:
In the example above I said about that man who had to write about the steps (and nifty details) related to an installation. But this also applies to requirements, test cases. We have the impression that if we will concentrate all our efforts on writing and managing by test cases is the way to go. Actually, it is a waste, a not so good direction because on testing we do much much more. There are so many aspects which can be covered that it is really hard to articulate it.
With this overemphasis on test cases we ignore the way we are and how we gain knowledge. Testing encompases many things like learning, critical thinking, experiencing and many others. A lot of this is not explicit but tacit.
For example, I said about critical thinking, this is for me a form of ostensive knowledge. I used 2 words to point to an entire discipline not so easy to describe and comprehend.
Learning about the product involves also understanding why certain decisions were made about that product. Being aware that certain knowledge will be kept secret without intention, mismatched silences or not being aware that an information is so important that needs to be shared-unrecognized knowledge.
Experiencing a certain product might not be easy at all. Information might popup only when discussing with persons involved in the process of working/developing with that product(collective tacit knowledge).
Connection with requirements:
Is helpful to have things written down especially for remembering them. In Scrum, for example, we write to remember but we do not write to communicate the Product Backlog Items(PBI’s) – the PO tells them.
Also this helps in setting more realistic expectations about written requirements.
Connection with management:
The story I gave was the moment when I understood the importance of theory and practice (praxis) , in this case regarding some aspects of tacit and explicit knowledge. As a manager it helped me to size up an unexpected situation and also be aware of things that might happen.