Quality assurance is the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures.
Processes include all of the activities involved in designing, developing, enhancing, and maintaining software.
Products include the software, associated data, its documentation, and all supporting and reporting paperwork.
QA includes the process of assuring that standards and procedures are established and are followed throughout the software development lifecycle.
Standards are the established criteria to which the software products are compared.
Procedures are the established criteria to which the development and control processes are compared.
Compliance with established requirements, standards, and procedures is evaluated through process monitoring, product evaluation, audits, and testing.
The three mutually supportive activities involved in the software development lifecycle are management, engineering, and quality assurance.
Software management is the set of activities involved in planning, controlling, and directing the software project.
Software engineering is the set of activities that analyzes requirements, develops designs, writes code, and structures databases.
Quality Assurance ensures that the management and engineering efforts result in a product that meets all of its requirements.
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.
Check out the Testing Effectiveness
QA Activities and Deliverables Within the Delivery Lifecycle
Each of the five phases of Project Delivery Lifecycle will incorporate QA activities and deliverables that off-set the risks of common project problems.
This summary of the Project Delivery Lifecycle incorporates a high-level list of the QA activities and deliverables associated with each phase.
Assessment process consists of market research and a series of structured workshops that the and client teams participate in to discuss and analyze the project objectives and develop a strategic plan for the effort. The products of these meetings, combined with market research, form the basis for the final output of the assessment: a tactical plan for realizing specific business and project objectives.
a) QA Editor submits revised and approved deliverable documents.
In the Planning phase, the team defines specific system requirements and develops strategies around the information architecture (static content and information flows) and the business functions that will be addressed.
a) Establishing Standards and Procedures: QA records the set requirements.
b) Planning (Test Matrix): QA develops a test matrix. QA confirms that all set requirements are testable and coincide with the project objectives.
c) Auditing Against Standards and Procedures: QA editor edits the documents and confirms that they meet the objectives and the quality standards for documents.
d) Establishing Completion Criteria: QA records the completion criteria for the current phase.
a) QA submits an initial test matrix.
b) QA Editor submits revised and approved deliverable documents.
During the Design phase, the team identifies all of the necessary system components based on the requirements identified during the Assessment and Planning phases. The team then creates detailed design specifications for each component and for the associated physical data requirements.
Auditing Standards and Procedures: QA confirms that all designs meet the set requirements and notes any discrepancies. Additionally, QA identifies any conflicts or discrepancies between the final design of the system and the initial proposal for the system and confirms that an acceptable resolution has been reached between the project team and the client.
Planning (QA Plan, QA Test Plan):
a) QA begins developing the QA Plan.
b) QA revised the test matrix to reflect any changes and/or additions to the system.
a) QA presents the initial QA test plan.
b) QA submits a revision of the test matrix.
During the Development phase, the team constructs the components specified during the Design Phase.
a) Planning (Test Cases): Using the test matrix, QA develops a set of test cases for all deliverable functionality for the current phase.
b) Prepare for Quality Assurance Testing:
c) QA confirms that all test cases have been written according to the guidelines set in the QA test plan.
d) Quality Assurance works closely with the Configuration Management group to prepare a test environment.
a) QA submits a set of Test Cases.
b) QA Environment is set up.
In the Implementation phase, the team focuses on testing and review of all aspects of the system. The team will also develop system documentation and a training or market test plan in preparation for system launch.
a) QA Testing: QA executes all test cases in the QA testing cycle.
a) Test Results
b) Defect Reports
QA and the Project Delivery Lifecycle
Common Project Problems
Like all software development activities, projects risk the following common technical and programmatic problems:
Inaccurate understanding of the project requirements.
Inflexibility; inability to adapt to changing requirements.
Modules that do not work together.
Late discovery of serious project flaws.
Scant record of who changed what, when, or why.
Limited roll-back capabilities
Such problems often stem from the following root causes:
Lack of communication; poor information work flow.
Lack of processes.
Lack of standards and/or procedures.
Lack of process for integration (the big picture).
Lack of solid testing methodology.
With the following programmatic components in place, the root causes of many common project problems may be corrected:
Controlled testing environment
Quality assurance testing
Standardized work flows for all of the components above