Let me share you my lesson learned of the last few days. How it happened, I don’t know, but I had some trouble with the communication. Afterwards is was not a big problem, but during the week it was hard enough. I’ll share with you the solution and some lessons I learned.

The project and the team
I’m in a small test team, with just a couple of testers, testing a smart card management system. The goal of this system is to manage all the smart cards with the certificates. These cards are used by almost 60.000 users with different roles in the Netherlands.

Our input documentation consists of a small functional design, a technical design (written after they build the software) and quite a few use cases. These are detailed enough for executing a kind of functional or acceptance testing. But we use these process oriented documentation for our system test (sound a little bit strange but it works).

To have, insight in the progress of the test team, they give me an update each day about the percentage of completion of the test based on the use cases they executed that specific day.

So far nothing strange; however I realized that the percentage of tests executed based on the uses cases were not the best way to measure the progress of the testing. (James Christie wrote a good post about why this type of measuring doesn’t work well)

The same message but different meaning
I requested my team to send me a daily update with an enumeration of the use cased followed by a percentage of completion. It looks like this:

Use case 010 request card: 100%
Use case 020 approve request: 100%
Use case 030 print smart card: 20%

The numbers where growing so we made some progress. The second part of the daily update are the defects found during the day.

This week a blocking defect occurred in the first use case, number 010. The result is that the last 70% of the use case can’t be tested because that part of the application is blocked.
The strange thing was that, the team reported a completion of 100% the day before, they found an blocking defect, still with a 100% completion. And use case 020 was also completed while this case get’s his input from 010.

As you may understand there was confusion between the test team and me. Because how can it happen that we have a blocking issue at 30%, we complete it 100% and also the next use case?

A little drawing gave us the solution
Clarity was needed in this discussion to be sure we’re heading in the same direction. I made a little drawing, based on what I expect what went wrong.

The thing was, when the team communicated to me that a certain use case was 100% completed, they mean they did all the things they could do in that specific situation. But what I understand was they are at 100% so they are finished.

A blocking issue at 30% of the test execution means from their point of view, we executed all test cases we can execute at this moment so we’re 100% complete.
I expected a completion of 30% in this case because the biggest part, 70%, isn’t covered.

Lessons learned from this incident
However this was not a big problem with effect on the project I had some general lessons learned These are my lessons learned on the way to successful communication:

• Be sure you have the same expectations
• Make drawings to clarify what you mean
• If you explained something, ask the other  what you mean
• Ask some questions about the progress the first times they delivered you the daily status update to be sure you understand the message
• Relate different aspects to each other, for example blocking issues in a certain part, and the completion of that part.
• Always keep in mind, in case of communication, nobody is right or wrong just be clear to each other.

1. Trackbacks Says:
   February 5th, 2012 at 23:09
   • Tweets that mention Clarity, the key for successful communication :: Software Testing and more — Topsy.com