Balance in Acceptance Testing

Among the different customers I had over the years, the level of knowledge has varied from very good to very shallow. This is absolutely all right! Why? Because they do not need to be all IT specialists. Nevertheless, the job must be done professionally.

It would be rather unrealistic to think that all companies must have a well-trained acceptance testing team, it is simply not necessary during most of the time of existence of that company. However, there is a moment when companies make a major turn and upgrade their IT systems to the most modern ones on the market, using the latest technology of the moment. This is the moment when they should have the most advanced testing team in order to verify and accept the product... but usually they don't.

On some of the projects I am faced with the situation where, as a system test manager, I need to offer support to acceptance testing teams that have never heard of testing.... most likely they have the impression that they do know testing after google-ing it for a few minutes. Or they are simply "borrowed" from the business department and put in a position where they "should know" what to do.  After years of rejecting the idea, now I accept that it is normal to find less knowledgeable testing teams in certain organizations. Why? Simply because the context in which they perform does not require that type of knowledge or that level of depth. It took me more than ten years to accurately know how software testing should be done, why should we ask this from people that are exposed to this job for a few months? We simply cannot!

We cannot put someone else in their place because:

1. The stakeholder trusts them (they have worked together for a long time and "trust" is there at a human level - much deeper than the professional level)

2. They know the business much better than anyone else... remember? They have worked in that environment for many years.

Coming to such a team with advanced theories regarding testing, arguments extracted from ISO standards or complex testing techniques will only dig a sinkhole between you and them and you can kiss your acceptance good bye.

The solution is balance. The supplier’s test manager should simplify the theory to such a level that it can be understood by the acceptance team. This point of balance will actually amplify the value that comes from their deep business experience.

My TaiChi master told me in a friendly discussion that when "I teach children I have to simplify the technique so much, maybe sometimes too much for my taste, so that they can understand and imitate it"

For me this was that AHA moment, that enlightenment regarding the point of balance between my team with more than 10 years of experience and an acceptance team what was exposed to testing for only a few months. I need to pass on to them a certain level of aggregated information so it can be easy to understand and use.

It struck me on the project I am involved now because after more than 5 months, the Beneficiary’s acceptance team did not approve or disapprove my performance test plan. I kept asking myself why the silence? The answer is simple: they are used to driving a normal car from point A to point B at a constant speed. Eventually they will get there by following all the turns and stops of the road. I am asking them to jump on a spaceship, enter hyperspace in point A and exit it in point B.

Simple recipe for not getting any answers :) So, I guess I need to follow my master's thought: simplify the notions and split them into essential small pieces so that they can easily understand and use them.

By doing that, from a 30 pages IEEE829 compatible document I extracted 4 pages of essence, which I will deliver maybe in smaller chunks. The rest is my job to see that it is respected and transparent for my customer.  

Simple ideas from simple discussions in a TaiChi dojo can change the path of IT projects worth millions of euros.