- In 90% of cases where acceptance testing fails, it is because of what’s been done before even starting it. If you pay attention to these points listed below when starting a development project, the probability to succeed increases substantially.
30% Execution + system testing is not fully ready
I’ve written several posts about this, for example: “Development Project Status: Everything is Ready, Except a Few Small Things”. Usually acceptance testing is started before it’s criteria is met. Root cause: The project is set up in a way where there is no visibility to the real state of readiness, as a whole: tasks, preparations, basic information, change requests, open issues.
20% Project’s problem solving ability is weak
Before starting testing, the process for handling change management and defect management needs to be in order. The meetings for defect management booked in advance, resource allocations made for vendors etc.
Problem: If the “Fix Factory” isn’t working, the number of open issues increases quickly. This is followed by testing slowdown, quality deterioration and schedule pressure.
10% Testers don’t know how to use the new application
Acceptance testing is not a place for training, even if testing teaches a lot. The savings made in briefing may later cost even more when testing is late, you need to buy outside support and all the unnecessary change requests pile up.
10% Not enough resources for testing
When I’ve gone through testing plans, most of the time testing resources allocated are about 30% of what is really needed. Here are some usual reasons for that:
- It’s calculated, that testers coming from the business test efficiently 7.5hrs/day. Real numbers are around 5.5hrs/day, because there’s always meetings and people need time for their own work as well.
- All the time needed for going through observations and retesting them is forgotten completely from the calculations. If all the processes and tools are in order, going through 100 observations and retesting them takes about 250 hours. If Excel and emails are the tools used, it takes over 300 hours.
- A plan is more like a wish, than a calculation. “We don’t have the resources to test more” or “It doesn’t take long to test one application really, does it?”
When this situation is included the fact that the resources are not booked on time, the game is over.
5% Preparations for testing is done poorly
Sometimes, making test documentation and preparing for testing is considered to be vexing. If there are problems with the execution, preparations are left as insufficient. Problem: It’s difficult to get testers to test efficiently, if you can’t give them simple tasks. This means that monitoring testing quality and progress becomes difficult.
It’s possible to make testing documentation agile. When you choose the right stage of detail, work load stays moderate.
5% Basic information is not ok
Testing will not work, if basic information is not OK. Testing with goofy data is not quality. Luckily nowadays the importance of basic information has sunk in quite well.
10% Team leader has no time to lead
If the team leader hasn’t reserved any time for management, the efficiency of testing suffers greatly. In time, more problems emerge, that really slow down testing. There are three difficult stages in acceptance testing:
- Starting: How to get the testers to test efficiently from the very beginning.
- Handling observations: How to make the Fix Factory and change management to work efficiently.
- Finishing testing (85% → 100%): Solving problems that prevent testing to be finished.
If you, as a team leader, have not reserved any time for managing, you are making the project expensive. Your troops are working inefficiently, because you have prioritized other work more important.
A lot of times in projects, people try to save by taking from testing. But no savings are made by setting up the testing poorly. If you want to test agile, the know-how and preparations need to be in order. Doing things at the right time is always cheaper than coming back to correct the mistakes.
