A consultant's tale
A few years ago, I went into a large multi-national bank to perform a consultancy task to review their testing practices. As a consultant, you get one of three types of reactions when you enter the building:
- A Groan – This is often because they have had bad experiences with consultants before and think this one will be no different. I don’t mind a groan, this often tells me that they have decent practices already and you won’t find much to worry about. This type of assignment is generally praising what they have done and recommending improvements in some areas.
- A Hurrah – This is the juicy assignment. A hurrah usually means that the workers know that what they are doing is insufficient and are hoping that the consultant will finally tell the bosses that they need to get their act together. This assignment often means that there are no (or very bad) practices and you are starting from ground zero.
- No reaction – These are the worrying and most hateful assignments. This often means that someone high up has called in a consultant with no buy-in from the staff and they are not going to co-operate with a single thing you do. You have an up-hill battle to even find a desk or get told where the toilets are. Your best bet is to do what you can, write the report and get out.
Anyway, back to this bank. I got the “Hurrah” reaction when I walked in. I soon found out why. In the section I had been called into, there was a development team of about 80 and 2 testers, yes, count them, 1, 2. These 2 testers were from one of the high street branches and had been called in a couple of years previously to give the system a quick once over before it went live. 2 years later, the system was still a mess. Some releases had gone to live and some of it even worked, but the system had some chronic problems.
I started doing the usual things for gathering information and it quickly became clear that the main problem was not only the testing (surprise!) but the Project Managers. One Project Manager, during my discussion with him stated “We incentivise our staff with a bonus which gets more the fewer bugs are found in the code”. I asked him how the tester was incentivised and he replied with a puzzled look on his face “The same, of course”. So, the testers got a greater bonus the fewer bugs they found!
The testers had been given no training in testing, they were both intelligent people but they were not IT people, they were business people. I asked them for their test plans and test scripts and it came as no surprise to me that I got a 1 page test plan and 2 pages of test script.
The reaction to the presentation I gave to the senior bosses was extremely positive. You could almost hear the sighs of relief around the room that the problems had been identified and that an action plan had been proposed. This came as a surprise to me as I was expecting some hostility (I had pulled no punches). It turned out that Director had not been with the bank for very long, which I knew, and he had been haranguing the senior managers about the lack of quality and they just didn’t know what to do about it – now they had a way forward.
That 4 week assignment to review their testing practices turned into a 4 year stint with them as they asked me to put the action plan in place. And a very happy 4 years they were for me. And I kept on the two business people, trained them and they became very effective business testers.
The lessons I learnt from this experience were:
· Just because it is a large company, it doesn’t mean they have good practices
· Senior IT managers do not always understand how to improve quality, they need telling.
· The situation of lack of testing in an organisation is an opportunity, not a reason to be depressed.
· “Shooting from the hip” sometimes works!