Section 7.5. Testing Quality

7.5. Testing Quality

As the saying goes, "You can't test quality into a product." During and after the project, you must test the results (interim and final) against the quality metrics and requirements specified to ensure the project is on track. No one in their right mind would create a project schedule and then look at it again on the final due date. The same holds true with quality. You can't just aim for quality then test it after all is said and done. You'll need to test for quality all along the way. In many IT projects, there is also a distinct quality testing process or phase a project goes through before the final product or deliverable is handed off to the user. It is during testing (both during and after the project work phase) that you hope to find any errors or defects that may have slipped through the process. The worst and usually most costly time to find errors or defects is once the project's deliverables have been handed over to the user, but the second worst time to find them is in the final testing phase, since it is always more expensive and more difficult to go back and fix problems at this point. As with monitoring quality, we'll discuss some of the quality testing components here to introduce you to terminology and concepts.

7.5.1. Prevention and Inspection

We mentioned earlier in this chapter that prevention is always more effective than inspection because you can't retrofit quality into a project; it has to be there from the beginning. Preventing errors and rework is always the goal, but there is a tradeoff between the level of desired quality and the cost. That tradeoff must be taken into account both from a user perspective and from a corporate perspective. You may be able to prevent 99.99% of all project errors, but the cost of the project results might be one hundred times what the market would pay for such a product. Inspection is how you ensure that your error/defect prevention is working and that your processes and procedures are generating the desired results. By periodically and thoroughly inspecting project results, you can ensure that the quality requirements and metrics are being met throughout the work of the project. Inspection also gives you the opportunity to make minor corrections before things veer too far off course. Inspection is sometimes referred to as project auditing, project review, and peer reviews.

7.5.2. Defined Quality Testing Procedures

Some IT projects require (and utilize) defined quality testing procedures. For instance, a software development project may have a dedicated quality control team responsible for designing tests that will put the software through its paces at each development stage and at the end of development. If your team or company has a defined quality testing procedure, it would be included in this phase.

7.5.3. Sampling

In some IT projects, sampling the project results is part of quality testing activities. Rather than inspecting every single line of code or every single network interface, you can achieve quality control at a lower cost through effective sampling techniques. Discussing sampling techniques is outside the scope of this book, but they are mentioned as a potentially useful tool you and your IT team may want to investigate.

7.5.4. Analysis

Analyzing project results throughout the project work cycle can also yield higher quality results. For instance, if an error or defect occurs in one area, analyzing the root cause or source may help reduce or avoid errors in another area. Analyzing the technical performance as well as the impact of errors or defects along the way can yield information you can use to finetune your project moving forward to further reduce errors.

7.5.5. Issue Resolution

Reviewing how issues are resolved is another component of quality testing. As you recall, issues should not only be tracked, they must also be resolved. The resolution of issues can point to areas of improvement in project processes and procedures or in other areas of the project. The action taken to resolve an issue can be helpful in improving other parts of the project and avoiding errors, omissions, and rework in subsequent phases of work. However, it's also true that the steps taken to resolve an issue may create a potential quality problem, so you should have a process in place to validate or test resolutions before they're implemented. Sometimes problems are simply solutions gone bad.

Cheat Sheet…
People, Technology, and Business

Remember that every IT project involves people, technology, and business. When you're developing your quality plans, make sure you keep these three factors in mind. Ask yourself, how can people contribute to the quality of this project? How can technology contribute to the quality of this project? How can our business contribute to the quality of this project (business processes, vendors, external relationships, and expertise are just a few ideas). When you look at these three areas for contributions to quality, you're bound to find a few that cost you nothing (or next to nothing) that you might otherwise have missed.

As the result of working through the steps in this chapter, you should have a solid quality management plan in place. This should be incorporated into you initial project plan so it can be an integral part of your project planning moving forward. Figure 7.3 depicts the outcome of this step, which is a quality management plan within the initial project plan.