Typically, a Quality Assurance (QA) program has at least 2 goals, which are:
1. Establish that the software meets the stated requirements.
2. Minimize the number of errors in the deployed software.
Measuring the QA processes effectiveness to these goals is straightforward (coverage and count reported errors), but the second goal may take years to identify the escaping errors. This brings us back to the question. To make a QA process more effective (meeting goals and costs), we need to know the characteristics of a QA process. Understanding the characteristics of a QA process also provides a basis to evaluate new techniques that may improve both the effectiveness and reduce the cost of quality.
In order to identify the Software Costs and Benefits, remembering Fujitsu's term with cost and performance as prime consideration, a number of Software Characteristics where defined.
These characteristics are sometimes referred to as Quality Attributes, Software Metrics or Functional and Non-Functional Requirements. The quality attributes are as follows
1. Functionality
2. Usability
3. Reliability
4.Performance
5. Supportability
I personally believe that these attributes should be defined with a set of well defined matrics. It reduces the number of errors in deployed software.
You may check this link
http://www.sqa.net/
Those are excellent attributes for assessing the quality of a delivered product, but what are the characteristics or attributes of the process being used to produce the evaluation.
In my experience, an important characteristic is the completeness of the product requirements. Requirements are rarely written out explicitly in a business context and instead are stored in different peoples memory. If a specific person has left the company, then those requirements are then mined from the code or from studying how a previous version of the product worked.
I. Gibbs
I agree the requirement completeness is important to the quality of the product. This is why Agile-Scrum has a stakeholder review at the end of each sprint.
However, It is possible to have a good QA process without complete requirements. In addition to the two attributes mentioned, one attribute that many regulatory agencies value the independence of the review. Independence of review is established by producing objective evidence that the software meets the stated user needs.
Carl,
The viewpoint of a stakeholder as to requirements completeness is entirely different than that of QA. For a business application, the requirements are generally very inadequate for the purpose of QA. In this case, QA needs to play an effective role in making the requirements more complete as to enable better testing. So, one characteristic is to either include QA as a stakeholder or include a requirements review and possible cleanup phase as part of the process.
Ivan
- Badges
- Science topic
- Similar topics
- Computer Science and Engineering
- Software