Programming Portal: GOALS OF QUALITY ASSURANCE

Software development, like any complex development activity, is a process full of risks. The risks are both technical and programmatic; that is, risks that the software or website will not perform as intended or will be too difficult to operate/browse, modify, or maintain are technical risks, whereas risks that the project will overrun cost or schedule are programmatic risks.

The goal of QA is to reduce these risks. For example, coding standards are established to ensure the delivery of quality code. If no standards are set, there exists a risk that the code will not meet the usability requirements, and that the code will need to be reworked.

If standards are set but there is no explicit process for assuring that all code meets the standards, then there is a risk that the code base will not meet the standards. Similarly, the lack of an Error Management and Defect Life Cycle workflow increases the risk that problems in the software will be forgotten and not corrected, or that important problems will not get priority attention.

The QA process is mandatory in a software development cycle to reduce these risks, and to assure quality in both the workflow and the final product. To have no QA activity is to increase the risk that unacceptable code will be released.

The Department of Quality Assurance

QA is an activity that should be organizationally independent of the producing organizations. QA functions are best performed in an discrete QA testing environment by organizational entities that are separate from the ones doing engineering or management activities. Administratively, the QA organization should report to top corporate management and interface with the project manager.

The reason for this separation of function is that the QA organization is the arm of management that assures that standards are met and that procedures are followed. If QA is not independent of the development activity, clear and impartial assessment will be difficult. Additionally, organizational independence helps ensure that testing will be requirements-driven and not influenced by the design or coding details.

Staff devoted purely to QA activities is usually small compared to the project staff, but it is important to have people with specific QA responsibilities. Too often, the axiom “quality is everybody's business” becomes “quality is nobody's business” if specific QA responsibilities are not assigned.