A major criticism leveled at project teams is lack of testing and this is a fair criticism in my view. Too many times I have seen the test phase glossed over, or some sort of half-hearted effort is made as an afterthought. The main culprit for poor testing is a failure to adequately plan properly and the responsibility lies firmly with the PM for not being disciplined in their approach.
Poor testing means poor product.
Poor product means a poor reputation – yours!
1. Plan for Testing!
After the above this sounds obvious, but it is so fundamental and such a commonly recurring mistake, I feel it is worth hammering home the point.
Your test plan should include all of your stated requirements and that includes all project deliverables and tangible products.
If you have to exclude testing some areas of the project, then make absolutely sure that this is documented and clearly specified in your SOW. More than this, make sure everyone, especially project stakeholders, agree to this exclusion and document this too.
Wherever possible, do not omit testing but instead look at use of automated testing tools as the next-best-option. The more testing you undertake, the more robust the finished product is going to be, and the risk of project failure, or partial failure, is minimized.
2. Identify & Engage Testers Early On In The Project
During the project resource planning phase, identify/assign who your testers will be. As soon as you have done so, you should engage them as early as is practical. Your testers will be able to identify testing approaches, write test scripts and assist in documentation, all of which will help how the project evolves.
More than this, testers are users, or at least they represent the end user, especially if you do not have a ‘real’ user seconded to your team. The more your testers know and understand the project, the better they will be able to formulate a testing regime.
3. Get On Top of Project Documentation Early!
Following tip #2, you will be providing testers with the opportunity to prepare at an early stage too. Ensure your testers do follow through with use cases and test script preparation. The optimal approach is to have this done during either the system design phase or when you are documenting requirements.
Successful PM users of HighGear will frequently upload all the materials into our system, which means they are available to all team members with access, and allows them to focus on end use, and how that will be tested, which in turn directs and influences how the project is developed.
This approach will also save you time, and more than this, when quality testing starts you can just flip the switch and plunge right in when testing needs to start.
4. Test to Destruction
By testing to destruction you will come up with a far more robust product, and this implies that you are going to find plenty of bugs!
Prepare yourself and your team for them: it is an instinctual and emotional reaction to discover errors. By preparing and managing expectations to begin with, the morale of both you and your team will be that much better plus you can focus on clearing bugs rather than finger-pointing or having a team whining session.
5. Analyze Results – Pass/Fail
Quality testing is pass or fail – if you have a fail, ensure you go through the implications and reasons for the failure with the team. You’re looking for a thorough analysis here, so you can get to the root cause of the error.
Ensure you are also very granular in your testing approach – high level testing is ineffective, and by being logical and thorough, you will identify reasons for failure that much faster.