There was a game when I was younger. We would work in pairs, and one of us would take a picture card. Then he would try to describe what’s on it while the other one would try to figure out what it was.
Sometimes we even tried to re-draw what the card-holding friend described. The outcomes were hilarious.
Transferring even the most simple ideas with just words is hard.
The same game continues in our professional lives. We have a combination of requirement specs, drawings, functional and non-functional requirements from the customer. And then there are the business requirements that we need to translate to technical ones.
The problem that we will always have is that when the customer is different from the person doing the product development we have an air gap. The gap between the customer’s mind and the developer’s mind.
And air gaps are always lossy!
Traditionally we’ve created specifications to freeze what the customers need so that the developer wouldn’t have to try to hit a moving target.
The challenge is to reduce the losses in the gap and ensure that the developer can accurately recreate what is inside the customers head.
As complexity grows, the potential for error-creep increases.
Some time ago I got involved in a competition as an advisor. Some friends of mine developed solutions that would reduce the pressure on the Accident & Emergency departments in the UK’s National Health Service.
The team could come up with any ideas they wanted, but the competition requirements meant that they had to fill in an online entry form where they described the functionality of the product, the business plan, the financials and so on.
Each form was limited to 500 words. It took several weeks for the guys to put the application together. By far, the most significant challenge for them was to get the concept of the idea across in sufficient detail with that word count.
Ultimately the team had it, and they even had some support from within the industry. The guys innovatively addressed a real-life problem. But of course, they lost.
Feedback was blunt. The judges didn’t understand the proposal. To me, it seemed that it was merely an adult version of the game we played as kids.
The point of the actual competition got lost in translation.
The specification is merely someone’s speculation of how the product should work. In addition to that, it tries to reduce an infinite amount of mind-residing information to words on papers.
Then, much later, the developer attempts to expand that data into a product once more.
Testing is here for a reason. To me, it is not to verify if the product matches the specification because then we only enforce the speculation and we never meet the original expectations of those who pay our bills.
To me, testing is here to close those gaps and to deal with the natural loss of information.
We do testing to build a broader band to a lossy channel of communication.