Answer: Level 1 – Validation
Validation is testing the software in an operational state. While there are several iterations of testing, they do not occur until the latter part of the system development life cycle. Thus, validation does not take advantage of the control theory stating that the control should be placed as close as possible to where the defect occurs. The most common types of validation are unit testing, integration testing, and system testing. Unit testing tests the smallest operating module of a system; integration testing tests the connecting logic between the modules/units; and the system testing validates that the system executes in the organization's operating environment.
Level 2 – Verification
Verification is the static testing of the system in a nonoperational status. It primarily tests the documentation produced by the project team. The documentation includes requirements, design,code, test, and operating documentation. Verification is performed through a variety of processes, including code analyzers, walkthroughs, reviews, and inspections. These verification processes also interact with the project team, end users, and other interested parties. Level 2 also incorporates acceptance testing, in which the end users define the criteria, which the system must meet in order to, be acceptable, and then test against those criteria.
Level 3 -- Defect Management
This level involves naming defects, counting defects, recording defects in a database, analyzing them, and then managing them throughout the entire life cycle of software. There are two types of defects, just as there are two types of quality. One defect is a variance from requirements/specifications, and the second defect is anything that dissatisfies the end user. For example, if the system was to add A plus B to get C, but in fact added A to X that would be a variance from specification defect. If the output was correct, but hard to use from an end user viewpoint, it would be an ease of use defect. Defects are generally only considered to be defects when they are uncovered in a task beyond the task in which the defect occurred. If the individual who makes the defect finds it during the same task, it is generally not considered to be a defect.
Level 4 -- Statistical Process Control
To be effective, statistical process control needs stabilized processes and defect recording. Some statistical process control techniques will be introduced at Level 3, but their use will be confined more to process improvement than for process management. Good statistical process control techniques require the type of measurement data that is only produced at Level 4. The statistical process control techniques will expand on root cause analysis, use sophisticated statistical tools and analysis, and create dashboards to be used in managing processes.
Level 5 - Preventive Management
This level is focused on preventing defects. It uses the lessons learned from the previous four levels of control/test to address the problems before they can become defects. During the previous four levels, the causes of defects are available and some addressed through process improvement. This level accelerates that trend and in addition provides the professional information staff with methods to modify the way work is performed so that the root causes of defects will not be built into software. This involves building risk models, developing defect expectation charts and/or defect profiles, and processes to customize processes so that the do component of processes can build software that is almost defect free.
