Verification
Reporting
Definition of Quality Criteria
Validation
Validation
Definition of Quality Criteria
18
User-oriented terms are potential factors, software-oriented terms are potential criteria;
Synonyms that are identified are grouped together.
The grouping helps to cover the comprehensive set of software quality factor characteristics desired.
Moreover, quality metrics should be introduced in the process of quality criteria definition as well -
they measure the relationship between the criteria or sub criteria and quality factors. After criteria and
related quality factors are defined, testing process starts by using validation and verification activities.
According to Hass (2008), these activities check whether the quality criteria have been met by the
specified software requirements under testing. In case the testing of particular functionality has failed
the validation and verification, a bug is reported and handed to the right authority for fixing. Once the
testing is passed to live up to the specified quality criteria, it should be provided in repots of passed
results. In both ways, QA reports on the findings and results should be generated. In order to keep
software quality it is essential follow the provided process of QA activities.
In addition to software quality through quality factors, it could be analyzed as the absence of
defects as well. According to Graham et al. (2008), the term defect in general determines a non-
compliance between the software functionality and specified requirements (or actual and expected
results of test). Sometimes the terms, defect, error, fault and failure, are used as synonyms, but each
term has a specified situation to be identified. The difference between these terms are distinguished by
Graham et al. (2008) and Hass (2008):
defect - a bug introduced by programmer inside the code that leads to non conformance
between the software functionality and specified requirements;
error - mistake made by a programmer (human action that produces an incorrect result) that
could be done because of some following reasons: confusion in understanding the functionality of the
software, some miscalculation of the values, misinterpretation of any value, etc.;
failure - the inability of a system or component to perform its required functions within
specified performance requirements (“IEEE Standard Glossary of Software Engineering
Terminology,” 1990).
Hass (2008) argues that the defect causes no harm until it is not encountered by anybody, but if it is
detected in a later phases of SDLC, it can rise to a failure. The types of error and defect in the different
stages of SDLC is shown in a figure below (see Figure 2, page 19). Failures affect the cost of software
development the most, so more attention should be paid on earlier stages of SDLC when defect cost is
the least.
19
Do'stlaringiz bilan baham: |