N this chapter, we will introduce you to the fundamentals of testing: why testing is

l
The recognition that we can
’t know the future, so changes to requirements are
welcomed throughout the development process, as this approach can produce a
product that better meets the stakeholders
’ needs as their knowledge grows over time.
l
The concept of shared code ownership among the developers, and the close
inclusion of testers in the sprint teams.
l
The writing of tests as the first step in the development of a component, and
the automation of those tests before any code is written. The component is
complete when it then passes the automated tests. This is known as
Test-Driven Development.
l
Simplicity: building only what is necessary, not everything you can think of.
l
The continuous integration and testing of the code throughout the sprint, at
least once a day.
Proponents of the Scrum and XP approaches emphasize testing throughout the
process. Each iteration (sprint) culminates in a short period of testing, often with an
independent tester as well as a business representative. Developers are to write and
run test cases for their code, and leading practitioners use tools to automate those
tests and to measure structural coverage of the tests (see Chapters 4 and 6). Every
time a change is made in the code, the component is tested and then integrated with
the existing code, which is then tested using the full set of automated component test
cases. This gives continuous integration, by which we mean that changes are
incorporated continuously into the software build.
Agile development provides both benefits and challenges for testers. Some of the
benefits are:
l
the focus on working software and good quality code;
l
the inclusion of testing as part of and the starting point of software development
(test-driven development);
l
accessibility of business stakeholders to help testers resolve questions about
expected behaviour of the system;
l
self-organizing teams where the whole team is responsible for quality and giving
testers more autonomy in their work; and
l
simplicity of design that should be easier to test.
There are also some significant challenges for testers when moving to an agile
development approach.
l
Testers used to working with well-documented requirements will be designing
tests from a different kind of test basis: less formal and subject to change. The
manifesto does not say that documentation is no longer necessary or that it has no
value, but it is often interpreted that way.
l
Because developers are doing more component testing, there may be a
perception that testers are not needed. But component testing and confirmation-
based acceptance testing by only business representatives may miss major
problems. System testing, with its wider perspective and emphasis on non-
functional testing as well as end to end functional testing is needed, even if it
doesn
’t fit comfortably into a sprint.
l
The tester
’s role is different: since there is less documentation and more personal
interaction within an agile team, testers need to adapt to this style of working, and
Section 1 Software Development Models 33

this can be difficult for some testers. Testers may be acting more as coaches in
testing to both stakeholders and developers, who may not have a lot of testing
knowledge.
l
Although there is less to test in one iteration than a whole system, there is also a
constant time pressure and less time to think about the testing for the new features.
l
Because each increment is adding to an existing working system, regression
testing becomes extremely important, and automation becomes more beneficial.
However, simply taking existing automated component or component
integration tests may not make an adequate regression suite.
Software engineering teams are still learning how to apply agile approaches.
Agile approaches cannot be applied to all projects or products, and some testing
challenges remain to be surmounted with respect to agile development. However,
agile methodologies are starting to show promising results in terms of both devel-
opment efficiency and quality of the delivered code.
2.1.3 Testing within a life cycle model
In summary, whichever life cycle model is being used, there are several character-
istics of good testing:
l
for every development activity there is a corresponding testing activity;
l
each test level has test objectives specific to that level;
l
the analysis and design of tests for a given test level should begin during the
corresponding development activity;
l
testers should be involved in reviewing documents as soon as drafts are
available in the development cycle.
2 . 2
T E S T L E V E L S
SYLLABUS LEARNING OBJECTIVES FOR
2.2 TEST LEVELS (K2)
LO-2.2.1 Compare the different levels of testing: major objectives,
typical objects of testing, typical targets of testing
(e.g. functional or structural) and related work products,
people who test, types of defects and failures to be
identified. (K2)
The V-model for testing was introduced in Section 2.1. In this section, we
’ll look in
more detail at the various test levels. The key characteristics for each test level are
discussed and defined to be able to more clearly separate the various test levels. A
thorough understanding and definition of the various test levels will identify missing
areas and prevent overlap and repetition. Sometimes we may wish to introduce
deliberate overlap to address specific risks. Understanding whether we want over-
laps and removing the gaps will make the test levels more complementary thus
leading to more effective and efficient testing.
34
Chapter 2 Testing throughout the software life cycle

While the specific test levels required for
– and planned for – a particular project
can vary, testing best practices suggest that each test level have the following clearly
identified:
l
The process, product and project objectives, ideally with measurable
effectiveness and efficiency metrics and targets.
l
The test basis, which are the work products used to derive the test cases.
l
The item, build, or system under test (also called the test object).
l
The typical defects and failures that we are looking for.
l
Any applicable requirements for test harnesses and tool support.
l
The approaches we intend to use.
l
The individuals who are responsible for the activities required to carry out the
fundamental test process for the test level.
When these topics are clearly understood and defined for the entire project team,
this contributes to the success of the project. In addition, during test planning, the
managers responsible for the test levels should consider how they intend to test a
system
’s configuration, if such data is part of a system.
As we go through this section, watch for the Syllabus terms acceptance testing,
alpha testing, beta testing, component testing, driver, efficiency testing, field
testing, functional requirement, integration testing, maintenance, non-functional
requirement, robustness testing, stub, system testing, test environment, test-driven
development, and user acceptance testing. You’ll find these terms defined in the
glossary.
2.2.1 Component testing
Component testing, also known as unit, module and program testing, searches for
defects in, and verifies the functioning of software items (e.g. modules, programs,
objects, classes, etc.) that are separately testable. Component tests are typically based
on the requirements and detailed design specifications applicable to the component
under test, as well as the code itself (which we
’ll discuss in Chapter 4 when we talk
about white box testing). The component under test, the test object, includes the
individual components (or even entire programs when the definition of components is
sufficiently broad), the data conversion and migration programs used to enable the
new release, and database tables, joins, views, modules, procedures, integrity and field
constraints, and even whole databases.
Component testing may be done in isolation from the rest of the system depending
on the context of the development life cycle and the system. Most often stubs and
drivers are used to replace the missing software and simulate the interface between
the software components in a simple manner. A stub is called from the software
component to be tested; a driver calls a component to be tested (see Figure 2.5).
Component testing may include testing of functionality and specific non-functional
characteristics such as resource-behaviour (e.g. memory leaks), performance or
robustness testing, as well as structural testing (e.g. decision coverage). Test cases
are derived from work products such as the software design or the data model.
Typically, component testing occurs with access to the code being tested and
with the support of the development environment, such as a unit test frame-work
or debugging tool, and in practice usually involves the programmer who wrote the
Efficiency testing The
process of testing to
determine the efficiency
of a software product.
Component testing
(unit testing, module
testing) The testing of
individual software
components. Note: the
ISTQB Glossary also lists
program testing as a
synonym, which is
somewhat confusing, but
consistent with the
definition given.
Stub A skeletal or
special-purpose
implementation of a
software component,
used to develop or test a
component that calls or is
otherwise dependent on
it. It replaces a called
component.
Driver (test driver) A
software component or
test tool that replaces a
component that takes
care of the control and/or
the calling of a
component or system.
Robustness
testing Testing to
determine the robustness
of the software product.
Section 2 Test Levels 35

code. Sometimes, depending on the applicable level of risk, component testing is
carried out by a different programmer thereby introducing independence. Defects
are typically fixed as soon as they are found, without formally recording the incidents
found.
One approach in component testing, used in Extreme Programming (XP), is to
prepare and automate test cases before coding. This is called a test-first approach
or test-driven development. This approach is highly iterative and is based on
cycles of developing test cases, then building and integrating small pieces of code,
and executing the component tests until they pass.
2.2.2 Integration testing
Integration testing tests interfaces between components, interactions to different
parts of a system such as an operating system, file system and hardware or interfaces
between systems. Integration tests are typically based on the software and system
design (both high-level and low-level), the system architecture (especially the
relationships between components or objects), and the workflows or use cases by
which the stakeholders will employ the system. The item under test, the test object,
includes the following: builds including some or all of the components or objects in
the system, the database elements applicable to the item under test, the system
infrastructure, the interfaces between components or objects, the system configura-
tion, and configuration data.
Note that integration testing should be differentiated from other integration
activities. Integration testing is often carried out by the integrator, but preferably
by a specific integration tester or test team.
There may be more than one level of integration testing and it may be carried out
on test objects of varying size. For example:
l
component integration testing tests the interactions between software
components and is done after component testing;
l
system integration testing tests the interactions between different systems and
may be done after system testing. In this case, the developing organization
may control only one side of the interface, so changes may be destabilizing.
Business processes implemented as workflows may involve a series of
systems that can even run on different platforms.
The greater the scope of integration, the more difficult it becomes to isolate failures
to a specific interface, which may lead to an increased risk. This leads to varying
approaches to integration testing. One extreme is that all components or systems are
Component:
Component:
A
B
A
Stub
Driver
B
F I G U R E 2 . 5
Stubs and drivers
Test-driven
development A way of
developing software
where the test cases are
developed, and often
automated, before the
software is developed to
run those test cases.
Integration testing
Testing performed to
expose defects in the
interfaces and in the
interactions between
integrated components
or systems.
36
Chapter 2 Testing throughout the software life cycle

integrated simultaneously, after which everything is tested as a whole. This is called
‘big-bang’ integration testing. Big-bang testing has the advantage that everything is
finished before integration testing starts. There is no need to simulate (as yet unfin-
ished) parts. The major disadvantage is that in general it is time-consuming and
difficult to trace the cause of failures with this late integration. So big-bang integration
may seem like a good idea when planning the project, being optimistic and expecting
to find no problems. If one thinks integration testing will find defects, it is a good
practice to consider whether time might be saved by breaking the down the integration
test process.
Another extreme is that all programs are integrated one by one, and a test is
carried out after each step (incremental testing). Between these two extremes, there
is a range of variants. The incremental approach has the advantage that the defects
are found early in a smaller assembly when it is relatively easy to detect the cause. A
disadvantage is that it can be time-consuming since stubs and drivers have to be
developed and used in the test. Within incremental integration testing a range of
possibilities exist, partly depending on the system architecture:
l
Top-down: testing takes place from top to bottom, following the control flow
or architectural structure (e.g. starting from the GUI or main menu).
Components or systems are substituted by stubs.
l
Bottom-up: testing takes place from the bottom of the control flow upwards.
Components or systems are substituted by drivers.
l
Functional incremental: integration and testing takes place on the basis of the
functions or functionality, as documented in the functional specification.
The preferred integration sequence and the number of integration steps required
depend on the location in the architecture of the high-risk interfaces. The best
choice is to start integration with those interfaces that are expected to cause most
problems. Doing so prevents major defects at the end of the integration test stage.
In order to reduce the risk of late defect discovery, integration should normally be
incremental rather than
‘big-bang’. Ideally testers should understand the architec-
ture and influence integration planning. If integration tests are planned before
components or systems are built, they can be developed in the order required for
most efficient testing.
At each stage of integration, testers concentrate solely on the integration itself.
For example, if they are integrating component A with component B they are
interested in testing the communication between the components, not the function-
ality of either one. Both functional and structural approaches may be used. Testing
of specific non-functional characteristics (e.g. performance) may also be included in
integration testing. Integration testing may be carried out by the developers, but can
be done by a separate team of specialist integration testers, or by a specialist group
of developers/integrators including non-functional specialists.
2.2.3 System testing
System testing is concerned with the behaviour of the whole system/product as
defined by the scope of a development project or product. It may include tests based
on risk analysis reports, system, functional, or software requirements specification,
business processes, use cases, or other high level descriptions of system behaviour,
interactions with the operating system, and system resources.
System testing The
process of testing an
integrated system to
verify that it meets
specified requirements.
Note: The ISTQB Glossary
derives from Hetzel
’s
book The Complete
Guide to Software
Testing, and the implied
objective of verification
might not be adequate
(or even appropriate) for
all projects when doing
system testing.
Section 2 Test Levels 37

The system under test, the test object, includes the following: the entire integrated
system, system, user and operation manuals, system configuration information, and
configuration data.
System testing is most often the final test on behalf of development to verify that the
system to be delivered meets the specification and its purpose may be to find as many
defects as possible. Most often it is carried out by specialist testers that form a
dedicated, and sometimes independent, test team within development, reporting to
the development manager or project manager. In some organizations system testing is
carried out by a third party team or by business analysts. Again the required level of
independence is based on the applicable risk level and this will have a high influence on
the way system testing is organized.
System testing should investigate both functional and non-functional require-
ments of the system. Typical non-functional tests include performance and reliability.
Testers may also need to deal with incomplete or undocumented requirements.
System testing of functional requirements starts by using the most appropriate
specification-based (black-box) techniques for the aspect of the system to be
tested. For example, a decision table may be created for combinations of effects
described in business rules. Structure-based (white-box) techniques may also be
used to assess the thoroughness of testing elements such as menu dialog
structure or web page navigation (see Chapter 4 for more on the various types
of technique).
System testing requires a controlled test environment with regard to, among other
things, control of the software versions, testware and the test data (see Chapter 5 for
more on configuration management). A system test is executed by the development
organization in a (properly controlled) environment. The test environment should
correspond to the final target or production environment as much as possible in
order to minimize the risk of environment-specific failures not being found by
testing.
2.2.4 Acceptance testing
When the development organization has performed its system test and has corrected all
or most defects, the system will be delivered to the user or customer for acceptance
testing (or user acceptance testing). Acceptance tests are typically based on user
requirements, system requirements, use cases, business processes, and risk analysis
reports. The system under test, the test object, includes the following: the business,
operational, and maintenance processes (evaluated on a fully integrated system), user
procedures, applicable forms, reports, and configuration data.
The acceptance test should answer questions such as:
‘Can the system be released?’,
‘What, if any, are the outstanding (business) risks?’ and ‘Has development met their
obligations?
’. Acceptance testing is most often the responsibility of the user or
customer, although other stakeholders may be involved as well. The execution of
the acceptance test requires a test environment that is for most aspects, representative
of the production environment (
‘as-if production’).
The goal of acceptance testing is to establish confidence in the system, part of
the system or specific non-functional characteristics, e.g. usability, of the system.
Acceptance testing is most often focused on a validation type of testing, whereby
we are trying to determine whether the system is fit for purpose. Finding defects
should not be the main focus in acceptance testing. Although it assesses the
system
’s readiness for deployment and use, it is not necessarily the final level of
Functional
requirement A
requirement that
specifies a function that a
component or system
must perform.
Non-functional
requirement A
requirement that does
not relate to
functionality, but to
attributes such as
reliability, efficiency,
usability, maintainability
and portability.
Test environment (test
bed) An environment
containing hardware,
instrumentation,
simulators, software
tools, and other support
elements needed to
conduct a test.
Acceptance testing
(acceptance, user
acceptance
testing) Formal testing
with respect to user
needs, requirements, and
business processes
conducted to determine
whether or not a system
satisfies the acceptance
criteria and to enable the
user, customers or other
authorized entity to
determine whether or
not to accept the system.
Maintenance
Modification of a
software product after
delivery to correct
defects, to improve
performance or other
attributes, or to adapt the
product to a modified
environment.
38
Chapter 2 Testing throughout the software life cycle

testing. For example, a large-scale system integration test may come after the
acceptance of a system.
Acceptance testing may occur at more than just a single level, for example:
l
A Commercial Off The Shelf (COTS) software product may be acceptance
tested when it is installed or integrated.
l
Acceptance testing of the usability of a component may be done during
component testing.
l
Acceptance testing of a new functional enhancement may come before system
testing.
Within the acceptance test for a business-supporting system, two main test
types can be distinguished; as a result of their special character, they are usually
prepared and executed separately. The user acceptance test focuses mainly on the
functionality thereby validating the fitness-for-use of the system by the business
user, while the operational acceptance test (also called production acceptance
test) validates whether the system meets the requirements for operation. The user
acceptance test is performed by the users and application managers. In terms of
planning, the user acceptance test usually links tightly to the system test and
will, in many cases, be organized partly overlapping in time. If the system to be
tested consists of a number of more or less independent subsystems, the accep-
tance test for a subsystem that complies to the exit criteria of the system test can
start while another subsystem may still be in the system test phase. In most
organizations, system administration will perform the operational acceptance
test shortly before the system is released. The operational acceptance test may
include testing of backup/restore, data load and migration tasks, disaster
recovery, user management, maintenance tasks and periodic check of security
vulnerabilities.
Other types of acceptance testing that exist are contract acceptance testing and
regulatory acceptance testing. Contract acceptance testing is performed against a
contract
’s acceptance criteria for producing custom-developed software. Acceptance
should be formally defined when the contract is agreed. Regulatory acceptance
testing or regulation acceptance testing is performed against the regulations which
must be adhered to, such as governmental, legal or safety regulations.
If the system has been developed for the mass market, e.g. commercial off-
the-shelf software (COTS), then testing it for individual users or customers is
not practical or even possible in some cases. Feedback is needed from potential
or existing users in their market before the software product is put out for sale
commercially. Very often this type of system undergoes two stages of accep-
tance test. The first is called alpha testing. This test takes place at the devel-
oper
’s site. A cross-section of potential users and members of the developer’s
organization are invited to use the system. Developers observe the users and
note problems. Alpha testing may also be carried out by an independent test
team. Beta testing, or field testing, sends the system to a cross-section of users
who install it and use it under real-world working conditions. The users send
records of incidents with the system to the development organization where the
defects are repaired.
Note that organizations may use other terms, such as factory acceptance testing
and site acceptance testing for systems that are tested before and after being moved
to a customer
’s site.
Alpha testing
Simulated or actual
operational testing by
potential users/customers
or an independent test
team at the developers
’
site, but outside the
development
organization. Alpha
testing is often employed
for off-the-shelf software
as a form of internal
acceptance testing.
Beta testing (field
testing) Operational
testing by potential and/
or existing users/
customers at an external
site not otherwise
involved with the
developers, to determine
whether or not a
component or system
satisfies the user/
customer needs and fits
within the business
processes. Beta testing is
often employed as a form
of external acceptance
testing for off-the-shelf
software in order to
acquire feedback from
the market.
Section 2 Test Levels 39

2 . 3
T E S T T Y P E S
SYLLABUS LEARNING OBJECTIVES FOR
2.3 TEST TYPES: (K2)
LO-2.3.1 Compare four software test types (functional, non-functional,
structural and change related) by example. (K2)
LO-2.3.2 Recognize that functional and structural tests occur at any test
level. (K1)
LO-2.3.3 Identify and describe non-functional test types based on
non-functional requirements. (K2)
LO-2.3.4 Identify and describe test types based on the analysis of a
software system’s structure or architecture. (K2)
LO-2.3.5 Describe the purpose of confirmation testing and regression
testing. (K2)
In this section, we
’ll look at different test types. We’ll discuss tests that focus on the
functionality of a system, which informally is testing what the system does. We
’ll
also discuss tests that focus on non-functionality attributes of a system, which
informally are testing how the system does what it does. We
’ll introduce testing
based on the system
’s structure. Finally, we’ll look at testing of changes to the
system, both confirmation testing (testing that the changes succeeded) and regres-
sion testing (testing that the changes didn
’t affect anything unintentionally).
The test types discussed here can involve the development and use of a model of the
software or its behaviours. Such models can occur in structural testing when we use
control flow models or menu structure models. Such models in non-functional testing
can involve performance models, usability models, and security threat models. Such
models can also arise in functional testing, such as the use of process flow models, state
transition models, or plain language specifications. Examples of such models will be
found in Chapter 4.
As we go through this section, watch for the Syllabus terms black box text
design technique, black box testing, code coverage, efficiency, functional
testing, functionality, functionality testing, interoperability testing, load test-
ing, maintainability, maintainability testing, performance testing, portabil-
ity, portability testing, reliability, reliability testing, robustness, security,
security testing, specification based testing, stress testing, structural based
testing, structural testing, test type, usability, usability testing, white-box
test design techniques and white-box testing. You’ll find these terms defined
in the glossary.
Test types are introduced as a means of clearly defining the objective of a certain
test level for a program or project. We need to think about different types of testing
because testing the functionality of the component or system may not be sufficient at
each level to meet the overall test objectives. Focusing the testing on a specific test
objective and, therefore, selecting the appropriate type of test helps make it easier to
make and communicate decisions about test objectives.
40
Chapter 2 Testing throughout the software life cycle

A test type is focused on a particular test objective, which could be the testing
of a function to be performed by the component or system; a non-functional
quality characteristic, such as reliability or usability; the structure or architecture
of the component or system; or related to changes, i.e. confirming that defects
have been fixed (confirmation testing, or re-testing) and looking for unintended
changes (regression testing). Depending on its objectives, testing will be organized
differently. For example, component testing aimed at performance would be quite
different to component testing aimed at achieving decision coverage.
2.3.1 Testing of function (functional testing)
The function of a system (or component) is
‘what it does’. This is typically described
in a requirements specification, a functional specification, in use cases, or, in agile
teams, in user stories. There may be some functions that are
‘assumed’ to be provided
that are not documented that are also part of the requirement for a system, though it is
difficult to test against undocumented and implicit requirements. Functional tests
are based on these functions, described in documents or understood by the testers
and may be performed at all test levels (e.g. test for components may be based on a
component specification).
Functional testing considers the specified behaviour and is often also referred to
as black-box testing (specification based testing). This is not entirely true, since
black-box testing also includes non-functional testing (see Section 2.3.2).
Function (or functionality) testing can, based upon ISO 9126, be done focus-
ing on suitability, interoperability testing, security, accuracy and compliance.
Security testing, for example, investigates the functions (e.g. a firewall) relating
to detection of threats, such as viruses, from malicious outsiders.
Testing functionality can be done from two perspectives: requirements-based or
business-process-based.
Requirements-based testing uses a specification of the functional requirements
for the system as the basis for designing tests. A good way to start is to use the table
of contents of the requirements specification as an initial test inventory or list of
items to test (or not to test). We should also prioritize the requirements based on risk
criteria (if this is not already done in the specification) and use this to prioritize the
tests. This will ensure that the most important and most critical tests are included in
the testing effort.
Business-process-based testing uses knowledge of the business processes. Busi-
ness processes describe the scenarios involved in the day-to-day business use of the
system. For example, a personnel and payroll system may have a business process
along the lines of: someone joins the company, he or she is paid on a regular basis,
and he or she finally leaves the company. Use cases originate from object-oriented
development, but are nowadays popular in many development life cycles. They also
take the business processes as a starting point, although they start from tasks to be
performed by users. Use cases are a very useful basis for test cases from a business
perspective.
The techniques used for functional testing are often specification-based, but
experienced-based techniques can also be used (see Chapter 4 for more on test
techniques). Test conditions and test cases are derived from the functionality of the
component or system. As part of test designing, a model may be developed, such as
a process model, state transition model or a plain-language specification.
Test type A group of
test activities aimed at
testing a component or
system focused on a
specific test objective, i.e.
functional test, usability
test, regression test etc. A
test type may take place
on one or more test levels
or test phases.
Functional
testing Testing based
on an analysis of the
specification of the
functionality of a
component or system.
Black-box testing
(specification based
testing) Testing, either
functional or
non-functional, without
reference to the internal
structure of the
component or system.
Functionality
testing The process of
testing to determine the
functionality of a
software product.
Interoperability
testing The process of
testing to determine the
interoperability of a
software product.
Security Attributes of
software products that
bear on its ability to
prevent unauthorized
access, whether
accidental or deliberate,
to programs and data.
Security testing Testing
to determine the security
of the software product.
Section 3 Test Types 41

2.3.2 Testing of software product characteristics
(non-functional testing)
A second target for testing is the testing of the quality characteristics, or non-
functional attributes of the system (or component or integration group). Here we
are interested in how well or how fast something is done. We are testing some-
thing that we need to measure on a scale of measurement, for example time to
respond.
Non-functional testing, as functional testing, is performed at all test levels. Non-
functional testing includes, but is not limited to, performance testing, load testing,
stress testing, usability testing, maintainability testing, reliability testing and
portability testing. It is the testing of ‘how well’ the system works.
Many have tried to capture software quality in a collection of characteristics
and related sub-characteristics. In these models some elementary characteristics
keep on reappearing, although their place in the hierarchy can differ. The Inter-
national Organization for Standardization (ISO) has defined a set of quality
characteristics [ISO/IEC 9126 2001]. This set reflects a major step towards con-
sensus in the IT industry and thereby addresses the general notion of software
quality. The ISO 9126 standard defines six quality characteristics and the subdivi-
sion of each quality characteristic into a number of sub-characteristics. This
standard is getting more and more recognition in the industry, enabling develop-
ment, testing and their stakeholders to use a common terminology for quality
characteristics and thereby for non-functional testing.
The characteristics and their sub-characteristics are, respectively:
l
functionality, which consists of five sub-characteristics: suitability, accuracy,
security, interoperability and compliance; this characteristic deals with
functional testing as described in Section 2.3.1;
l
reliability, which is defined further into the sub-characteristics maturity
(robustness), fault-tolerance, recoverability and compliance;
l
usability, which is divided into the sub-characteristics understandability,
learnability, operability, attractiveness and compliance;
l
efficiency, which is divided into time behaviour (performance), resource
utilization and compliance;
l
maintainability, which consists of five sub-characteristics: analyzability,
changeability, stability, testability and compliance;
l
portability, which also consists of five sub-characteristics: adaptability,
installability, co-existence, replaceability and compliance.
A common misconception is that non-functional testing occurs only during
higher levels of testing such as system test, system integration test, and acceptance
test. In fact, non-functional testing may be performed at all test levels; the higher the
level of risk associated with each type of non-functional testing, the earlier in the
lifecycle it should occur. Ideally, non-functional testing involves tests that quantifi-
ably measure characteristics of the systems and software. For example, in perfor-
mance testing we can measure transaction throughput, resource utilization, and
response times. Generally, non-functional testing defines expected results in terms
of the external behaviour of the software. This means that we typically use black-
box test design techniques.
Performance
testing The process of
testing to determine the
performance of a
software product.
Load testing A type of
performance testing
conducted to evaluate
the behaviour of a
component or system
with increasing load, e.g.
numbers of parallel users
and/or numbers of
transactions, to
determine what load can
be handled by the
component or system.
Stress testing A type of
performance testing
conducted to evaluate a
system or component at
or beyond the limits of its
anticipated or specified
work loads, or with
reduced availability of
resources such as access
to memory or servers.
Usability testing
Testing to determine the
extent to which the
software product is
understood, easy to learn,
easy to operate and
attractive to the users
under specified conditions.
Maintainability
testing The process of
testing to determine the
maintainability of a
software product.
Reliability testing The
process of testing to
determine the reliability
of a software product.
Portability testing The
process of testing to
determine the portability
of a software product.
42
Chapter 2 Testing throughout the software life cycle

2.3.3 Testing of software structure/architecture
(structural testing)
The third target of testing is the structure of the system or component. If we are
talking about the structure of a system, we may call it the system architecture.
Structural testing is often referred to as
‘white-box’ or ‘glass-box’ because we are
interested in what is happening
‘inside the box’.
Structural testing is most often used as a way of measuring the thoroughness of
testing through the coverage of a set of structural elements or coverage items. It can
occur at any test level, although it is true to say that it tends to be mostly applied at
component and integration and generally is less likely at higher test levels, except for
business-process testing. At component integration level it may be based on the
architecture of the system, such as a calling hierarchy. The test basis for system,
system integration or acceptance testing could be a business model or menu structure.
At component level, and to a lesser extent at component integration testing, there is
good tool support to measure code coverage. Coverage measurement tools assess the
percentage of executable elements (e.g. statements or decision outcomes) that have been
exercised (i.e. covered) by a test suite. If coverage is not 100%, then additional tests may
need to be written and run to cover those parts that have not yet been exercised. This of
course depends on the exit criteria. (Coverage techniques are covered in Chapter 4.)
The techniques used for structural testing are structure-based techniques, also
referred to as white-box test design techniques. Control flow models are often used
to support structural testing.
2.3.4 Testing related to changes (confirmation
and regression testing)
The final target of testing is the testing of changes. This category is slightly different
to the others because if you have made a change to the software, you will have
changed the way it functions, the way it performs (or both) and its structure.
However we are looking here at the specific types of tests relating to changes, even
though they may include all of the other test types.
Confirmation testing (re-testing)
When a test fails and we determine that the cause of the failure is a software defect, the
defect is reported, and we can expect a new version of the software that has had the
defect fixed. In this case we will need to execute the test again to confirm that the defect
has indeed been fixed. This is known as confirmation testing (also known as re-testing).
When doing confirmation testing, it is important to ensure that the test is executed in
exactly the same way as it was the first time, using the same inputs, data and environment.
If the test now passes does this mean that the software is now correct? Well, we now know
that at least one part of the software is correct
– where the defect was. But this is not enough.
The fix may have introduced or uncovered a different defect elsewhere in the software.
The way to detect these
‘unexpected side-effects’ of fixes is to do regression testing.
Regression testing
Like confirmation testing, regression testing involves executing test cases that have
been executed before. The difference is that, for regression testing, the test cases
probably passed the last time they were executed (compare this with the test cases
executed in confirmation testing
– they failed the last time).
Functionality The
capability of the software
product to provide
functions which meet
stated and implied needs
when the software is used
under specified conditions.
Reliability The ability of
the software product to
perform its required
functions under stated
conditions for a specified
period of time, or for a
specified number of
operations.
Robustness The degree
to which a component or
system can function
correctly in the presence
of invalid inputs or
stressful environmental
conditions.
Usability The capability
of the software to be
understood, learned,
used and attractive to the
user when used under
specified conditions.
Efficiency The capability
of the software product to
provide appropriate
performance, relative to the
amount of resources used
under stated conditions.
Maintainability The
ease with which a
software product can be
modified to correct
defects, modified to meet
new requirements,
modified to make future
maintenance easier, or
adapted to a changed
environment.
Portability The ease
with which the software
product can be
transferred from one
hardware or software
environment to another.
Section 3 Test Types 43

The term
‘regression testing’ is something of a misnomer. It would be better if it were
called
‘anti-regression’ testing because we are executing tests with the intent of check-
ing that the system has not regressed (that is, it does not now have more defects in it
as a result of some change). More specifically, the purpose of regression testing is
to verify that modifications in the software or the environment have not caused
unintended adverse side effects and that the system still meets its requirements.
It is common for organizations to have what is usually called a regression test
suite or regression test pack. This is a set of test cases that is specifically used for
regression testing. They are designed to collectively exercise most functions (cer-
tainly the most important ones) in a system but not test any one in detail. It is
appropriate to have a regression test suite at every level of testing (component
testing, integration testing, system testing, etc.). All of the test cases in a regression
test suite would be executed every time a new version of software is produced and
this makes them ideal candidates for automation. If the regression test suite is very
large it may be more appropriate to select a subset for execution.
Regression tests are executed whenever the software changes, either as a result of
fixes or new or changed functionality. It is also a good idea to execute them when some
aspect of the environment changes, for example when a new version of a database
management system is introduced or a new version of a source code compiler is used.
Maintenance of a regression test suite should be carried out so it evolves over
time in line with the software. As new functionality is added to a system new
regression tests should be added and as old functionality is changed or removed so
too should regression tests be changed or removed. As new tests are added a
regression test suite may become very large. If all the tests have to be executed
manually it may not be possible to execute them all every time the regression suite is
used. In this case a subset of the test cases has to be chosen. This selection should be
made in light of the latest changes that have been made to the software. Sometimes a
regression test suite of automated tests can become so large that it is not always
possible to execute them all. It may be possible and desirable to eliminate some test
cases from a large regression test suite for example if they are repetitive (tests which
exercise the same conditions) or can be combined (if they are always run together).
Another approach is to eliminate test cases that have not found a defect for a long
time (though this approach should be used with some care!).
2 . 4
M A I N T E N A N C E T E S T I N G
SYLLABUS LEARNING OBJECTIVES FOR 2.4 MAINTENANCE
TESTING (K2)
LO-2.4.1 Compare maintenance testing (testing an existing system) to
testing a new application with respect to test types, triggers for
testing and amount of testing. (K2)
LO-2.4.2 Recognize indicators for maintenance testing (modification,
migration and retirement). (K1)
LO-2.4.3 Describe the role of regression testing and impact analysis in
maintenance. (K2)
Black-box
(specification-based)
test design
technique Procedure to
derive and/or select test
cases based on an
analysis of the
specification, either
functional or non-
functional, of a
component or system
without reference to its
internal structure.
White-box testing
(structural testing,
structure-based
testing) Testing based
on an analysis of the
internal structure of the
component or system.
Code coverage An
analysis method that
determines which parts
of the software have
been executed (covered)
by the test suite and
which parts have not
been executed, e.g.
statement coverage,
decision coverage or
condition coverage.
White-box (structural,
structure-based) test
design
technique Procedure to
derive and/or select test
cases based on an
analysis of the internal
structure of a component
or system.
44
Chapter 2 Testing throughout the software life cycle

Once deployed, a system is often in service for years or even decades. During this
time the system and its operational environment is often corrected, changed or
extended. Testing that is executed during this life cycle phase is called
‘mainte-
nance testing’. Maintenance testing, along with the entire process of maintenance
releases, must be carefully planned in advance. Not only must planned maintenance
releases be considered, but the process for developing and testing hot fixes must be
as well. Maintenance testing includes any type of testing of changes to an existing,
operational system, whether the changes result from modifications, migration, or
retirement of the software or system.
Modifications can result from planned enhancement changes such as those
referred to as
‘minor releases’ that include new features and accumulated (non-
emergency) bug fixes. Modifications can also result from corrective and more-
urgent emergency changes. Modifications can also involve changes of environment,
such as planned operating system or database upgrades, planned upgrade of
Commercial-Off-The-Shelf software, or patches to correct newly exposed or dis-
covered vulnerabilities of the operating system.
Migration involves moving from one platform to another. This can involve
abandoning a platform no longer supported, or adding a new supported platform.
Either way, testing must include operational tests of the new environment as well as
of the changed software. Migration testing can also include conversion testing, where
data from another application will be migrated into the system being maintained.
Note that maintenance testing is different from maintainability testing, which
defines how easy it is to maintain the system). In this section, we
’ll discuss maintenance
testing.
As we go through this section, watch for the Syllabus terms impact analysis and
maintenance testing. You’ll find these terms defined in the glossary.
The development and test process applicable to new developments does not
change fundamentally for maintenance purposes. The same test process steps will
apply and, depending on the size and risk of the changes made, several levels of
testing are carried out: a component test, an integration test, a system test and an
acceptance test. A maintenance test process usually begins with the receipt of an
application for a change or a release plan. The test manager will use this as a basis
for producing a test plan. On receipt of the new or changed specifications, corre-
sponding test cases are specified or adapted. On receipt of the test object, the new
and modified tests and the regression tests are executed. On completion of the
testing, the testware is once again preserved.
Comparing maintenance testing to testing a new application is merely a matter of
an approach from a different angle, which gives rise to a number of changes in
emphasis. There are several areas where most differences occur, for example regard-
ing the test basis. A
‘catching-up’ operation is frequently required when systems are
maintained. Specifications are often
‘missing’, and a set of testware relating to the
specifications simply does not exist. It may well be possible to carry out this catching-
up operation along with testing a new maintenance release, which may reduce the
cost. If it is impossible to compile any specifications from which test cases can be
written, including expected results, an alternative test basis, e.g. a test oracle, should
be sought by way of compromise. A search should be made for documentation which
is closest to the specifications and which can be managed by developers as well as
testers. In such cases it is advisable to draw the customer
’s attention to the lower test
quality which may be achieved. Be aware of possible problems of
‘daily production’.
In the worst case nobody knows what is being tested, many test cases are executing
Maintenance
testing Testing the
changes to an
operational system or the
impact of a changed
environment to an
operational system.
Section 4 Maintenance Testing 45

the same scenario and if an incident is found, it is often hard to trace it back to the
actual defect since no traceability to test designs and/or requirements exists. Note that
reproducibility of tests is also important for maintenance testing.
One aspect which, in many cases, differs somewhat from the development
situation is the test organization. New development and their appropriate test
activities are usually carried out as parts of a project, whereas maintenance tests
are normally executed as an activity in the regular organization. As a result, there is
often some lack of resources and flexibility, and the test process may experience
more competition from other activities.
2.4.1 Impact analysis and regression testing
Usually maintenance testing will consist of two parts:
l
testing the changes
l
regression tests to show that the rest of the system has not been affected by the
maintenance work.
In addition to testing what has been changed, maintenance testing includes
extensive regression testing to parts of the system that have not been changed. A
major and important activity within maintenance testing is impact analysis. During
impact analysis, together with stakeholders, a decision is made on what parts of the
system may be unintentionally affected and therefore need careful regression testing.
Risk analysis will help to decide where to focus regression testing
– it is unlikely
that the team will have time to repeat all the existing tests.
If the test specifications from the original development of the system are kept, one
may be able to reuse them for regression testing and to adapt them for changes to the
system. This may be as simple as changing the expected results for your existing tests.
Sometimes additional tests may need to be built. Extension or enhancement to the
system may mean new areas have been specified and tests would be drawn up just as
for the development. Don
’t forget that automated regression tests will also need to be
updated in line with the changes; this can take significant effort, depending on the
architecture of your automation.
2.4.2 Triggers for maintenance testing
As stated maintenance testing is done on an existing operational system. It is triggered
by modifications, migration, or retirement of the system. Modifications include planned
enhancement changes (e.g. release-based), corrective and emergency changes, and
changes of environment, such as planned operating system or database upgrades, or
patches to newly exposed or discovered vulnerabilities of the operating system. Main-
tenance testing for migration (e.g. from one platform to another) should include
operational testing of the new environment, as well as the changed software. Main-
tenance testing for the retirement of a system may include the testing of data migration
or archiving, if long data-retention periods are required.
Since modifications are most often the main part of maintenance testing for most
organizations, this will be discussed in more detail. From the point of view of testing,
there are two types of modifications. There are modifications in which testing may be
planned, and there are ad-hoc corrective modifications, which cannot be planned at
all. Ad-hoc corrective maintenance takes place when the search for solutions to
defects cannot be delayed. Special test procedures are required at that time.
Impact analysis The
assessment of change to
the layers of
development
documentation, test
documentation and
components, in order to
implement a given
change to specified
requirements.
46
Chapter 2 Testing throughout the software life cycle

Planned modifications
The following types of planned modification may be identified:
l
perfective modifications (adapting software to the user
’s wishes, for instance by
supplying new functions or enhancing performance);
l
adaptive modifications (adapting software to environmental changes such as new
hardware, new systems software or new legislation);
l
corrective planned modifications (deferrable correction of defects).
The standard structured test approach is almost fully applicable to planned mod-
ifications. On average, planned modification represents over 90% of all maintenance
work on systems [Pol and van Veenendaal 1998].
Ad-hoc corrective modifications
Ad-hoc corrective modifications are concerned with defects requiring an immedi-
ate solution, e.g. a production run which fails late at night, a network that goes
down with a few hundred users on line, a mailing with incorrect addresses. There
are different rules and different procedures for solving problems of this kind. It
will be impossible to take the steps required for a structured approach to testing. If,
however, a number of activities are carried out prior to a possible malfunction, it
may be possible to achieve a situation in which reliable tests can be executed in
spite of
‘panic stations’ all round. To some extent this type of maintenance testing
is often like first aid
– patching up – and at a later stage the standard test process is
then followed to establish a robust fix, test it and establish the appropriate level of
documentation.
A risk analysis of the operational systems should be performed in order to establish
which functions or programs constitute the greatest risk to the operational services in
the event of disaster. It is then established
– in respect of the functions at risk – which
(test) actions should be performed if a particular malfunction occurs. Several types of
malfunction may be identified and there are various ways of responding to them for
each function at risk. A possible reaction might be that a relevant function at risk
should always be tested, or that, under certain circumstances, testing might be carried
out in retrospect (the next day, for instance). If it is decided that a particular function at
risk should always be tested whenever relevant, a number of standard tests, which
could be executed almost immediately, should be prepared for this purpose. The
standard tests would obviously be prepared and maintained in accordance with the
structured test approach.
Even in the event of ad-hoc modifications, it is therefore possible to bring about
an improvement in quality by adopting a specific test approach. It is important to
make a thorough risk analysis of the system and to specify a set of standard tests
accordingly.
Section 4 Maintenance Testing 47

C H A P T E R R E V I E W
Let
’s review what you have learned in this chapter.
From Section 2.1, you should now understand the relationship between develop-
ment and testing within a development life cycle, including the test activities and test
(work) products. You should know that the development model to use should fit, or
must be adapted to fit, the project and product characteristics. You should be able to
recall the reasons for different levels of testing and characteristics of good testing in
any life cycle model. You should know the glossary terms agile manifesto, agile
software development, Commercial Off-The-Shelf (COTS), incremental develop-
ment model, integration, iterative development model, performance, require-
ment, test level, validation, verification, and V-model.
From Section 2.2, you should know the typical levels of testing. You should be
able to compare the different levels of testing with respect to their major objec-
tives, typical objects of testing, typical targets of testing (e.g. functional or
structural) and related work products. You should also know which persons per-
form the testing activities at the various test levels, the types of defects found and
failures to be identified. You should know the glossary terms acceptance testing,
alpha testing, beta testing, component testing, driver, efficiency testing, field
testing, functional requirement, integration testing, manitenance, non-
functional requirement, robustness testing, stub, system testing, test driven
development, test environment and user acceptance testing.
From Section 2.3, you should know the four major types of test (functional, non-
functional, structural and change-related) and should be able to provide some concrete
examples for each of these. You should understand that functional and structural tests
occur at any test level and be able to explain how they are applied in the various test
levels. You should be able to identify and describe non-functional test types based on
non-functional requirements and product quality characteristics. Finally you should be
able to explain the purpose of confirmation testing (re-testing) and regression testing
in the context of change-related testing. You should know the glossary terms black
box text design technique, black box testing, code coverage, efficiency, functional
testing, functionality, functionality testing, interoperability testing, load testing,
maintainability, maintainability testing, performance testing, portability, port-
ability testing, reliability, reliability testing, robustness, security, security testing,
specification based testing, stress testing, structural based testing, structural
testing, test type, usability, usability testing, white-box test design techniques
and white-box testing.
From Section 2.4, you should be able to compare maintenance testing to testing of
new applications. You should be able to identify triggers and reasons for maintenance
testing, such as modifications, migration and retirement. Finally you should be able to
describe the role of regression testing and impact analysis within maintenance testing.
You should know the glossary terms impact analysis and maintenance testing.
48
Chapter 2 Testing throughout the software life cycle

S A M P L E E X A M Q U E S T I O N S
Question 1 What are good practices for testing
within the development life cycle?
a. Early test analysis and design.
b. Different test levels are defined with specific
objectives.
c. Testers will start to get involved as soon as coding
is done.
d. A and B above.
Question 2 Which option best describes objectives
for test levels with a life cycle model?
a. Objectives should be generic for any test level.
b. Objectives are the same for each test level.
c. The objectives of a test level don
’t need to be
defined in advance.
d. Each level has objectives specific to that level.
Question 3 Which of the following is a test type?
a. Component testing
b. Functional testing
c. System testing
d. Acceptance testing
Question 4 Which of the following is a non-
functional quality characteristic?
a. Feasibility
b. Usability
c. Maintenance
d. Regression
Question 5 Which of these is a functional test?
a. Measuring response time on an on-line booking
system.
b. Checking the effect of high volumes of traffic in a
call-center system.
c. Checking the on-line bookings screen information
and the database contents against the information
on the letter to the customers.
d. Checking how easy the system is to use.
Question 6 Which of the following is a true
statement regarding the process of fixing emergency
changes?
a. There is no time to test the change before it goes
live, so only the best developers should do this
work and should not involve testers as they slow
down the process.
b. Just run the retest of the defect actually fixed.
c. Always run a full regression test of the whole
system in case other parts of the system have been
adversely affected.
d. Retest the changed area and then use risk
assessment to decide on a reasonable subset of the
whole regression test to run in case other parts of
the system have been adversely affected.
Question 7 A regression test:
a. Is only run once.
b. Will always be automated.
c. Will check unchanged areas of the software to see
if they have been affected.
d. Will check changed areas of the software to see if
they have been affected.
Question 8 Non-functional testing includes:
a. Testing to see where the system does not function
correctly.
b. Testing the quality attributes of the system
including reliability and usability.
c. Gaining user approval for the system.
d. Testing a system feature using only the software
required for that function.
Question 9 Beta testing is:
a. Performed by customers at their own site.
b. Performed by customers at the software
developer
’s site.
c. Performed by an independent test team.
d. Useful to test software developed for a specific
customer or user.
Sample Exam Questions 49

CHAPTER THREE
Static techniques
S
tatic test techniques provide a powerful way to improve the quality and productivity
of software development. This chapter describes static test techniques, including
reviews, and provides an overview of how they are conducted. The fundamental
objective of static testing is to improve the quality of software work products by
assisting engineers to recognize and fix their own defects early in the software
development process. While static testing techniques will not solve all the problems,
they are enormously effective. Static techniques can improve both quality and
productivity by impressive factors. Static testing is not magic and it should not be
considered a replacement for dynamic testing, but all software organizations should
consider using reviews in all major aspects of their work including requirements, design,
implementation, testing, and maintenance. Static analysis tools implement automated
checks, e.g. on code.
3 . 1
S T A T I C T E C H N I Q U E S A N D T H E T E S T
P R O C E S S
SYLLABUS LEARNING OBJECTIVES FOR
3.1 STATIC TECHNIQUES AND THE TEST PROCESS (K2)
LO-3.1.1 Recognize software work products that can be examined by
the different static techniques. (K1)
LO-3.1.2 Describe the importance and value of considering static
techniques for the assessment of software work products. (K2)
LO-3.1.3 Explain the difference between static and dynamic techniques,
considering objectives, types of defects to be identified, and the
role of these techniques within the software life cycle. (K2)
In this section, we consider how static testing techniques fit into the overall test process.
Dynamic testing requires that we run the item or system under test, but static testing
techniques allow us to find defects directly in work products, without the execution of
the code and without the need to isolate the failure to locate the underlying defect. Static
techniques include both reviews and static analysis, each of which we
’ll discuss in this
chapter. Static techniques are efficient ways to find and remove defects, and can find
certain defects that are hard to find with dynamic testing. As we go through this section,
watch for the Syllabus terms dynamic testing and static testing. You’ll find these
terms defined in the glossary.
50

In Chapter 1, several testing terms were presented. Also testing itself was defined. The
latter definition is repeated here as a means for explaining the two major types of testing.
The definition of testing outlines objectives that relate to evaluation, revealing
defects and quality. As indicated in the definition two approaches can be used to
achieve these objectives, static testing and dynamic testing.
With dynamic testing methods, software is executed using a set of input values and
its output is then examined and compared to what is expected. During static testing,
software work products are examined manually, or with a set of tools, but not
executed. As a consequence, dynamic testing can only be applied to software code.
Dynamic execution is applied as a technique to detect defects and to determine quality
attributes of the code. This testing option is not applicable for the majority of the
software work products. Among the questions that arise are: How can we evaluate or
analyze a requirements document, a design document, a test plan, or a user manual?
How can we effectively examine the source code before execution? One powerful
technique that can be used is static testing, e.g. reviews. In principle all software work
products can be tested using review techniques.
Dynamic testing and static testing are complementary methods, as they tend to find
different types of defects effectively and efficiently. Types of defects that are easier to
find during static testing are: deviations from standards, missing requirements, design
defects, non-maintainable code and inconsistent interface specifications. Compared to
dynamic testing, static testing finds defects rather than failures.
In addition to finding defects, the objectives of reviews are often also informational,
communicational and educational, whereby participants learn about the content of
software work products to help them understand the role of their own work and to
plan for future stages of development. Reviews often represent project milestones, and
support the establishment of a baseline for a software product. The type and quantity of
defects found during reviews can also help testers focus their testing and select effective
classes of tests. In some cases customers/users attend the review meeting and provide
feedback to the development team, so reviews are also a means of customer/user
communication.
Studies have shown that as a result of reviews, a significant increase in productivity
and product quality can be achieved [Gilb and Graham 1993], [van Veenendaal 1999].
Reducing the number of defects early in the product life cycle also means that less time
has to be spent on testing and maintenance. To summarize, the use of static testing, e.g.
reviews, on software work products has various advantages:
l
Since static testing can start early in the life cycle, early feedback on quality
issues can be established, e.g. an early validation of user requirements and not
just late in the life cycle during acceptance testing.
l
By detecting defects at an early stage, rework costs are most often relatively low
and thus a relatively cheap improvement of the quality of software products
can be achieved.
l
Since rework effort is substantially reduced, development productivity figures
are likely to increase.
l
The evaluation by a team has the additional advantage that there is an
exchange of information between the participants.
l
Static tests contribute to an increased awareness of quality issues.
In conclusion, static testing is a very suitable method for improving the quality of
software work products. This applies primarily to the assessed products themselves,
Static testing Testing of
a component or system
at specification or
implementation level
without execution of that
software, e.g. reviews or
static analysis.
Dynamic testing
Testing that involves the
execution of the software
of a component or
system.
Section 1 Static Techniques and the Test Process 51

but it is also important that the quality improvement is not achieved once but has a
more permanent nature. The feedback from the static testing process to the develop-
ment process allows for process improvement, which supports the avoidance of
similar errors being made in the future.
3 . 2
R E V I E W P R O CE S S
SYLLABUS LEARNING OBJECTIVES FOR
3.2 REVIEW PROCESS (K2)
LO-3.2.1 Recall the activities, roles and responsibilities of a typical
formal review. (K1)
LO-3.2.2 Explain the differences between different types of reviews:
informal review, technical review, walkthrough and
inspection. (K2)
LO-3.2.3 Explain the factors for successful performance of reviews. (K2)
In this section, we will focus on reviews as a distinct
– and distinctly useful – form of
static testing. We
’ll discuss the process for carrying out reviews. We’ll talk about who
does what in a review meeting and as part of the review process. We
’ll cover types of
reviews that you can use, and success factors to enable the most effective and efficient
reviews possible. As we go through this section, watch for the Syllabus terms entry
criteria, formal review, informal review, inspection, metric, moderator, peer
review, reviewer, scribe, technical review, and walkthrough. You’ll find these
terms defined in the glossary.
Reviews vary from very informal to formal (i.e. well structured and regulated).
Although inspection is perhaps the most documented and formal review technique,
it is certainly not the only one. The formality of a review process is related to
factors such as the maturity of the development process, any legal or regulatory
requirements or the need for an audit trail. In practice the informal review is perhaps
the most common type of review. Informal reviews are applied at various times
during the early stages in the life cycle of a document. A two-person team can
conduct an informal review, as the author can ask a colleague to review a document
or code. In later stages these reviews often involve more people and a meeting. This
normally involves peers of the author, who try to find defects in the document under
review and discuss these defects in a review meeting. The goal is to help the author
and to improve the quality of the document. Informal reviews come in various
shapes and forms, but all have one characteristic in common
– they are not
documented.
3.2.1 Phases of a formal review
In contrast to informal reviews, formal reviews follow a formal process. A typical
formal review process consists of six main steps (Please note
– due to a formatting
error, some versions of the ISTQB Foundation Syllabus version 2010 show a 12 step
process, with obvious formatting problems. As of the time of writing, these problems
Informal review A
review not based on a
formal (documented)
procedure.
Formal review A review
characterized by
documented procedures
and requirements, e.g.
inspection.
52
Chapter 3 Static techniques

have been corrected in the ISTQB Foundation Syllabus version 2011, and the proper
version of the process is shown here):
Typical formal review steps
1
Planning
2
Kick-off
3
Preparation
4
Review meeting
5
Rework
6
Follow-up
Planning
The Foundation Syllabus specifies the following elements of the planning step:
l
Defining the review criteria.
l
Selecting the personnel.
l
Allocating roles.
l
Defining the entry and exit criteria for more formal review types (e.g. inspections).
l
Selecting which parts of documents to review.
l
Checking entry criteria (for more formal review types).
Let
’s examine these in more detail.
The review process for a particular review begins with a
‘request for review’ by
the author to the moderator (or inspection leader). A moderator is often assigned to
take care of the scheduling (dates, time, place and invitation) of the review. On a
project level, the project planning needs to allow time for review and rework
activities, thus providing engineers with time to thoroughly participate in reviews.
For more formal reviews, e.g. inspections, the moderator always performs an entry
check and defines at this stage formal exit criteria. The entry check is carried out to
ensure that the reviewers
’ time is not wasted on a document that is not ready for review.
A document containing too many obvious mistakes is clearly not ready to enter a formal
review process and it could even be very harmful to the review process. It would possibly
de-motivate both reviewers and the author. Also, the review is most likely not effective
because the numerous obvious and minor defects will conceal the major defects.
Although more and other entry criteria can be applied, the following can be
regarded as the minimum set for performing the entry check:
l
A short check of a product sample by the moderator (or expert) does not reveal a
large number of major defects. For example, after 30 minutes of checking, no
more than three major defects are found on a single page or fewer than ten major
defects in total in a set of five pages.
l
The document to be reviewed is available with line numbers.
l
The document has been cleaned up by running any automated checks that apply.
l
References needed for the inspection are stable and available.
l
The document author is prepared to join the review team and feels confident
with the quality of the document.
If the document passes the entry check, the moderator and author decide which

tải về 6.34 Mb.

Chia sẻ với bạn bè của bạn: