Saturday, January 26, 2008

Play the tune you know best!

James Bach made a posting on his blog Why Labels For Test Techniques? This triggered me thinking about communication of testers, between testers and testers communicating with systems. When I read that post for the first time I had some flashbacks about some situations I was into over the last years. In some projects there were testers who had experience in testing and understand the "test-language" I spoke. On other projects there were dedicated testers from the business having the assignment to test, understanding the business processes very well only had no education in the "test-language". This did not make them better or worse testers.

In my opinion we use labels, for example test techniques, to communicate with other testers. To make sure we understand each other about those things. And the rules to apply those techniques are the grammar rules of our language.

If this is indeed our grammar, we might have a risk if we don't know our grammar well we get some noise in our communication which might result in not testing the things we intend to do. The combination of noise in communication reminded me of a model I once learned: The Shannon-Weaver-Model from that site looks like:



In combination with that model I learned about terms like verbal and non-verbal communication. Where some researcher claiming that >90% of our communication is non-verbal. Though I don't have the exact books which confirms this statement, here an article who is mentioning and explaining it Non Verbal Communication

Think about when 10% of our communication is verbal, test techniques are used to present that communication, and then there should be more resources for us testers to measure our test process or quality of the system.

What has the grammar, the Shannon-Weaver-Model and the differentiation between verbal and non-verbal to do with testing? And what might be the relations between these objects?

Imagine what happens if we don't know our grammar well, or don't even speak the same language assuming that only 10% of our communication is done using the products of this grammar to speak to each other or to speak to the system we want to test. The chance we have noise in our communication will increase and by this the chance we don't test the system we ought to do. If we don't the test the system we ought to do we might give wrong conclusions.


I can imagine that applying the model towards Human-Human communication might be clear and the question rose how this can be translates to Human-System communication. In this I made the assumption that we communicate with for example test scripts to a system under test. Here I see the requirements as source, the encoder is the tester, the channel is the PC, the decoder and receiver is the system under test and the behavior of the system is the feedback we receive. This is the verbal part of the communication of the Human-System. The non-verbal part could be the attitude the tester has. For example if he looks happy, then the scripts might be executable and the system response as expected in the scripts. If the tester groans, there might be something wrong with the system, environmont or even with the test scripts.

How can we improve our communication?
Perhaps these steps might help:

  1. Identify the skill level of the testers;
  2. Determine the labels and grammar in combination of skill-level;
  3. Agree on labels and grammar how we communicate;
  4. Review the products as result of applying the communication labels;
  5. Apply the products in communication with each other and towards the system (verbal);
  6. Define measurement moments based on Shannon-Weaver-model when to check the non-verbal communication;
  7. Clarify or adjust grammar rules or change communication language


To identify the skill level of the testers you can check on several items like: understanding the # of test methods, understanding the number of test techniques, ability of using those techniques. Assume we take the number of techniques as criteria then you might use these classifications:

  1. Those who know no techniques;
  2. Those who know about 3 techniques;
  3. Those who know >3 techniques.

Of course there are more classifications to think about still 3 is a nice number. Here also starts the non-verbal communication part. You should not only act on the answers they give about knowing those numbers. You also should pay attention towards their attitude when you are asking them explicitly using test techniques. Hesitation might be a sign of not knowing those techniques or perhaps lack of trust in on selves about those techniques.

As said in a project I worked with testers without no knowledge about testing techniques. This made them not less valuable and able to test. Instead of using those test technique names like boundary, equivalence, interval testing I used other labels they understand.

This brings me to step 2: Determine the language and grammar. In that situation I used the following labels:

  1. Basic functionality
  2. Business Rules
  3. Screen/ Layout/ Forms/ Reports
  4. Exceptional/ Combinations / Negative

To get an agreement you have to ask them personally. When sending out an email or a document you will miss the non-verbal communication. A stand-up meeting might be a good tool to check if they fully understand and agree. When we agreed about the definition and meaning of these labels they continue thinking about test cases based on their experience with the system and processes. And they classified their test cases as such.

Using these labels helped me to check the purpose of their test cases and translate it for me to those techniques I know about and see whether we could extend their test cases. In this case the step 4 is executed by me using my test knowledge.

Now the real testing begins. (step 5) The testers can execute their test scripts. They communicate verbally (instead of spoken words, written words) with the system. They also communicate non-verbally. If for example they hit the machine or looking depressed there might be signs of something not wrong. This might be worth to check upon. Here the monitor process starts. If this behavior results in raised issues, they translate the response of the system on verbal level. If it doesn't result in a raised issue, then we have a chance of missing defects in the system. Or perhaps a flaw in the test script or test process. Perhaps you know more items we can check upon?

Only keep in mind that continues monitoring of testers might have an contrarily result. The tester might feel uncomfortable and signs of communication might become false signs. To avoid this we have also to agree on the moments we monitor. We sort of open the communication.

If communication is important in testing. And usage of grammar is a tool. We might consider the project goals and the personal goals in perspective. In short I mean with this that if there is lack of time and quality should be granted on a certain level there might be lesser time to teach the testers on their skills with newer techniques. In this case using those techniques they know might be a choice. I think it is better to apply those techniques you know instead of intending to use those you know for half as the result might be interpreted wrong. This is similar to "Play the tune you know best!" learning tunes while playing might result in bad tunes. And some people might become unhappy hearing those.

It is better to use 1 techniques you know best instead of using all for just a part and claiming you used them. As a claim might result in expectations.

No comments:

Post a Comment