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.
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.
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.
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.
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:
When this situation is included the fact that the resources are not booked on time, the game is over.
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.
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.
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:
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.
Download a guide on software testing in development projects. You’ll avoid many common mistakes and succeed in the implementation.
Improved testing efficiency, 70% less emails and real time reporting
Easily plan and execute even the most challenging development project