This is a list of Testing Standards.

1. WWW.UNIVERSALEXAMS.COM
Software Testing Standards Overview
This document provides an overview of standards referenced from the ISEB Intermediate
Certificate in Software Testing Syllabus.
IEEE 1028 generic process for formal reviews
IEEE Std 1028 defines a common set of activities for "formal" reviews (with some variations,
especially for software audit). The sequence of activities is largely based on the software
inspection process originally developed at IBM by Michael Fagan. Differing types of review
may apply this structure with varying degrees of rigour, but all activities are mandatory for
inspection:
•
0. [Entry evaluation]: The Review Leader uses a standard checklist of entry criteria
to ensure that optimum conditions exist for a successful review.
•
1. Management preparation: Responsible management ensure that the review will
be appropriately resourced with staff, time, materials, and tools, and will be
conducted according to policies, standards, or other relevant criteria.
•
2. Planning the review: The Review Leader identifies or confirms the objectives of
the review, organises a team of Reviewers, and ensures that the team is equipped
with all necessary resources for conducting the review.
•
3. Overview of review procedures: The Review Leader, or some other qualified
person, ensures (at a meeting if necessary) that all Reviewers understand the review
goals, the review procedures, the materials available to them, and the procedures for
conducting the review.
•
4. [Individual] Preparation: The Reviewers individually prepare for group
examination of the work under review, by examining it carefully for anomalies
(potential defects), the nature of which will vary with the type of review and its goals.
•
5. [Group] Examination: The Reviewers meet at a planned time to pool the results
of their preparation activity and arrive at a consensus regarding the status of the
document (or activity) being reviewed.
•
6. Rework/follow-up: The Author of the work product (or other assigned person)
undertakes whatever actions are necessary to repair defects or otherwise satisfy the
requirements agreed to at the Examination meeting. The Review Leader verifies that
all action items are closed.
•
7. [Exit evaluation]: The Review Leader verifies that all activities necessary for
successful review have been accomplished, and that all outputs appropriate to the
type of review have been finalised.
Copyright © 2007 www.universalexams.com

2. WWW.UNIVERSALEXAMS.COM
ISO/IEC 12207
Software lifecycle processes are methods and standards for improving and mastering
development processes, supporting processes and management processes throughout the
software lifecycle.
The quest for the optimized mix of processes has resulted in different standards throughout
the history of software development. One of the latest which was published is the ISO/IEC
12207 standard. This standard was proposed in 1988 and published in August 1995. It was
created to establish a common international framework to acquire, supply, develop, operate,
and maintain software.
ISO/IEC 12207 consists of three types of processes:
•
•
•
Primary lifecycle processes;
Supporting lifecycle processes;
Organizational lifecycle processes.
Because the complete ISO/IEC 12207 standard is very elaborate this entry will only explain
some, more interesting, parts of the primary lifecycle processes.
In this entry the word “product” will be used instead of system, software product or software
service.
Primary lifecycle processes
The primary lifecycle processes contain the core processes involved in creating a software
product. These processes are divided into five different main processes:
•
•
•
•
•
Acquisition
Supply
Development
Operation
Maintenance
In the next chapters the activities and deliverables of the primary lifecycle processes are
presented.
Because the primary lifecycle processes cover a very large area a scope was defined. This
entry explains all the primary lifecycle processes but will explain the processes ‘Acquisition’
and ‘Development’ more extensively.
Copyright © 2007 www.universalexams.com

3. WWW.UNIVERSALEXAMS.COM
IEEE 829
IEEE 829-1998, also known as the 829 Standard for Software Test Documentation, is an
IEEE standard that specifies the form of a set of documents for use in eight defined stages of
software testing, each stage potentially producing its own separate type of document. The
standard specifies the format of these documents but does not stipulate whether they all must
be produced, nor does it include any criteria regarding adequate content for these documents.
These are a matter of judgment outside the purview of the standard. The documents are:
Test Plan: a management planning document that shows:
How the testing will be done (including SUT configurations).
Who will do it
What will be tested
How long it will take (although this may vary, depending upon resource availability).
What the test coverage will be, i.e. what quality level is required
Test Design Specification: detailing test conditions and the expected results as well as test
pass criteria.
Test Case Specification: specifying the test data for use in running the test conditions
identified in the Test Design Specification
Test Procedure Specification: detailing how to run each test, including any set-up
preconditions and the steps that need to be followed
Test Item Transmittal Report: reporting on when tested software components have
progressed from one stage of testing to the next
Test Log: recording which tests cases were run, who ran them, in what order, and whether
each test passed or failed
Test Incident Report: detailing, for any test that failed, the actual versus expected result, and
other information intended to throw light on why a test has failed. This document is
deliberately named as an incident report, and not a fault report. The reason is that a
discrepancy between expected and actual results can occur for a number of reasons other
than a fault in the system. These include the expected results being wrong, the test being run
wrongly, or inconsistency in the requirements meaning that more than one interpretation
could be made. The report consists of all details of the incident such as actual and expected
results, when it failed, and any supporting evidence that will help in its resolution. The report
will also include, if possible, an assessment of the impact upon testing of an incident.
Test Summary Report: A management report providing any important information uncovered
by the tests accomplished, and including assessments of the quality of the testing effort, the
quality of the software system under test, and statistics derived from Incident Reports. The
report also records what testing was done and how long it took, in order to improve any future
test planning. This final document is used to indicate whether the software system under test
is fit for purpose according to whether or not it has met acceptance criteria defined by project
stakeholders.
Copyright © 2007 www.universalexams.com

4. WWW.UNIVERSALEXAMS.COM
ISO 9126
ISO 9126 is an international standard for the evaluation of software. It will be overseen by the
project SQuaRE, ISO 25000:2005, which follows the same general concepts.
The standard is divided into four parts which addresses, respectively, the following subjects:
quality model; external metrics; internal metrics; and quality in use metrics.
The quality model established in the first part of the standard, ISO 9126-1, classifies software
quality in a structured set of characteristics and sub-characteristics as follows:
•
Functionality - A set of attributes that bear on the existence of a set of functions and
their specified properties. The functions are those that satisfy stated or implied needs.
o Suitability
o Accuracy
o Interoperability
o Compliance
o Security
•
Reliability - A set of attributes that bear on the capability of software to maintain its
level of performance under stated conditions for a stated period of time.
o Maturity
o Recoverability
o Fault Tolerance
•
Usability - A set of attributes that bear on the effort needed for use, and on the
individual assessment of such use, by a stated or implied set of users.
o Learnability
o Understandability
o Operability
•
Efficiency - A set of attributes that bear on the relationship between the level of
performance of the software and the amount of resources used, under stated
conditions.
o Time Behaviour
o Resource Behaviour
•
Maintainability - A set of attributes that bear on the effort needed to make specified
modifications.
o Stability
o Analyzability
o Changeability
o Testability
•
Portability - A set of attributes that bear on the ability of software to be transferred
from one environment to another.
o Installability
o Replaceability
o Adaptability
Copyright © 2007 www.universalexams.com

5. WWW.UNIVERSALEXAMS.COM
The sub-characteristic Conformance is not listed above and applies to all characteristics.
Examples are conformance to legislation concerning Usability or Reliability.
Each quality sub-characteristic (as adaptability) is further divided into attributes. An attribute is
an entity which can be verified or measured in the software product. Attributes are not defined
in the standard, as they vary between different software products.
Software product is defined in a broad sense: it encompasses executables, source code,
architecture descriptions, and so on. As a result, the notion of user extends to operators as
well as to programmers, which are users of components as software libraries.
The standard provides a framework for organizations to define a quality model for a software
product. On doing so, however, it leaves up to each organization the task of specifying
precisely its own model. This may be done, for example, by specifying target values for
quality metrics which evaluates the degree of presence of quality attributes.
Internal metrics are those which do not rely on software execution (static measures).
External metrics are applicable to running software.
Quality in use metrics are only available when the final product is used in real conditions.
Ideally, the internal quality determines the external quality and external quality determines
quality in use.
This standard stems from the model established in 1977 by McCall and his colleagues, who
proposed a model to specify software quality. The McCall quality model is organized around
three types of Quality Characteristics:
•
•
•
Factors (To specify): They describe the external view of the software, as viewed by
the users.
Criteria (To build): They describe the internal view of the software, as seen by the
developer.
Metrics (To control): They are defined and used to provide a scale and method for
measurement.
ISO 9126 distinguishes between a defect and a nonconformity, a defect being The
nonfulfilment of intended usage requirements, whereas a nonconformity is The nonfulfilment
of specified requirements. A similar distinction is made between validation and verification,
known as V&V in the testing trade.
Copyright © 2007 www.universalexams.com

6. WWW.UNIVERSALEXAMS.COM
BS 7925-1
BS 7925-1 is a Glossary of Software Testing Terms, along with its partner BS 7925-2
Software component testing.
The standard was developed by the Testing Standards Working Party and published in
August 1998. This is a volunteer group devoted to the development of new software testing
standards and sponsored by the BCS SIGiST (British Computer Society Specialist Interest
Group in Software Testing).
The standard may be ordered from BSI but it is not cheap. Alternatively, free copies of the
latest draft SIGIST standard and an up-to-date 'living' Glossary can be downloaded from the
Testing Standards website.
BS 7925-2
BS 7925-2 is the Software Component Testing Standard, along with its partner BS 7925-1
which is a Glossary of Software Testing Terms.
The standard was developed by the Testing Standards Working Party and published in
August 1998. This is a volunteer group devoted to the development of new software testing
standards and sponsored by the BCS SIGiST (British Computer Society Specialist Interest
Group in Software Testing).
The standard may be ordered from BSI but it is not cheap. Alternatively, free copies of the
latest draft SIGIST standard and an up-to-date 'living' Glossary can be downloaded from the
Testing Standards website.
Other standards that may be of interest are:
•
•
•
•
•
•
•
•
•
•
IEEE 1008, a standard for unit testing
IEEE 1012, a standard for Software Verification and Validation
IEEE 1028, a standard for software inspections
IEEE 1044, a standard for the classification of software anomalies
IEEE 1044-1, a guide to the classification of software anomalies
IEEE 1233, a guide for developing system requirements specifications
IEEE 730, a standard for software quality assurance plans
IEEE 1061, a standard for software quality metrics and methodology
BSS 7925-1, a vocabulary of terms used in software testing
BSS 7925-2, a standard for software component testing
Copyright © 2007 www.universalexams.com