part of a test status report, or as part as an end-of-project test summary

project, understanding the purpose of testing means knowing the answers to
questions such as:
l
What is in scope and what is out of scope for this testing effort?
l
What are the test objectives?
l
What are the important project and product risks? (More on risks in Section 5.5.)
l
What constraints affect testing (e.g. budget limitations, hard deadlines, etc.)?
l
What is most critical for this product and project?
l
Which aspects of the product are more (or less) testable?
l
What should be the overall test execution schedule and how should we decide the
order in which to run specific tests? (Product and planning risks, discussed later
in this chapter, will influence the answers to these questions.)
You should then select strategies which are appropriate to the purpose of testing
(more on the topic of selecting strategies in a few pages).
In addition, you need to decide how to split the testing work into various levels,
as discussed in Chapter 2 (e.g. component, integration, system and acceptance). If
that decision has already been made, you need to decide how to best fit your testing
work in the level you are responsible for with the testing work done in those other
test levels. During the analysis and design of tests, you
’ll want to reduce gaps and
overlap between levels and, during test execution, you
’ll want to coordinate between
the levels. Such details dealing with inter-level coordination are often addressed in
the master test plan.
In addition to integrating and coordinating between test levels, you should also
plan to integrate and coordinate all the testing work to be done with the rest of the
project. For example, what items must be acquired for the testing? Are there on-
going supply issues, such as with imitation bills (i.e. simulated banknotes) for a
financial application such as an ATM? When will the programmers complete work
on the system under test? What operations support is required for the test environ-
ment? What kind of information must be delivered to the maintenance team at the
end of testing?
Moving down into the details, what makes a plan a plan
– rather than a statement
of principles, a laundry list of good ideas or a collection of suggestions
– is that the
author specifies in it who will do what when and (at least in a general way) how.
I E E E 8 2 9 S T A N D A R D T E S T P LA N T E M P LA T E
Test plan identifier
Introduction
Test items
Features to be tested
Features not to be tested
Approach
Item pass/fail criteria
Suspension and resumption criteria
Test deliverables
Test tasks
Environmental needs
Responsibilities
Staffing and training needs
Schedule
Risks and contingencies
Approvals
128
Chapter 5 Test management

Resources are required to carry out the work. These are often hard decisions that
require careful consideration and building a consensus across the team, including
with the project manager.
The entire testing process
– from planning through to closure – produces
information, some of which you will need to document. How precisely should
testers write the test designs, cases and procedures? How much should they leave
to the judgment of the tester during test execution, and what are the reproducibility
issues associated with this decision? What kinds of templates can testers use for the
various documents they
’ll produce? How do those documents relate to one another?
If you intend to use tools for tasks such as test design and execution, as discussed in
Chapter 6, you
’ll need to understand how the models or automated tests will
integrate with manual testing and plan and who will be responsible for automation
design, implementation and support. There may be a separate Test Automation Plan,
but this needs to be coordinated with other Test Plans.
Some information you
’ll need to gather in the form of raw data and then distil.
What metrics to do you intend to use to monitor, control and manage the testing?
Which of those metrics
– and perhaps other metrics – will you use to report your
results? We
’ll look more closely at possible answers to those questions in Section 5.3,
but a good test plan provides answers early in the project.
Finally, moving back up to a higher level, think about what would be true about
the project when the project was ready to start executing tests. What would be true
about the project when the project was ready to declare test execution done? At what
point can you safely start a particular test level or phase, test suite or test target?
When can you finish it? The factors to consider in such decisions are often called
‘entry criteria’ and ‘exit criteria.’
Typical factors for entry criteria are:
l
Acquisition and supply: the availability of staff, tools, systems, test
environments, test data, and other materials required.
l
Test items: the state that the items to be tested must be in to start and to finish
testing.
Typical factors for exit criteria are:
l
Defects: the number known to be present, the arrival rate, the number predicted
to remain, and the number resolved.
l
Tests: the number prepared, run, passed, failed, blocked, skipped, and so forth.
l
Coverage: the extent to which the test basis, risk, functionality, supported
configurations, and the software code have been tested
– or have not.
l
Quality: the status of the important quality characteristics for the system, the
estimated number of defects present or remaining, and other attributes.
l
Money: the cost of finding the next defect in the current level of testing compared
to the cost of finding it in the next level of testing (or in production).
l
Schedule: the project schedule implications of starting or ending testing.
l
Risk: the undesirable outcomes that could result from shipping too early (such as
latent defects or untested areas)
– or too late (such as loss of market share).
When writing exit criteria, we try to remember that a successful project is a
balance of quality, budget, schedule and feature considerations. This is even more
important when applying exit criteria at the end of the project.
Section 2 Test Planning and Estimation 129

5.2.3 Estimating what testing will involve and what it will cost
The testing work to be done can often be seen as a subproject within the larger
project. So, we can adapt fundamental techniques of estimation for testing.
We could start with a work-breakdown structure that identifies the stages, activities
and tasks.
Starting at the highest level, we can break down a testing project into phases
using the fundamental test process identified in the ISTQB Syllabus: planning and
control; analysis and design; implementation and execution; evaluating exit criteria
and reporting; and test closure. Within each phase we identify activities and within
each activity we identify tasks and perhaps subtasks. To identify the activities and
tasks, we work both forward and backward. When we say we work forward, we
mean that we start with the planning activities and then move forward in time step
by step, asking,
‘Now, what comes next?’
Working backward means that we consider the risks that we identified during
risk analysis (which we
’ll discuss in Section 5.5). For those risks which you intend
to address through testing, ask yourself,
‘So, what activities and tasks are required in
each stage to carry out this testing?
’ Let’s look at an example of how you might
work backward.
Suppose that you
’ve identified performance as a major area of risk for your
product. So, performance testing is an activity in the test execution phase. You now
estimate the tasks involved with running a performance test, how long those tasks
will take and how many times you
’ll need to run the performance tests.
Now, those tests didn
’t just appear out of thin air: someone had to develop them.
So, performance test development entails activities in test analysis, design and
implementation. You now estimate the tasks involved in developing a performance
test, such as writing test scripts and creating test data.
Typically, performance tests need to be run in a special test environment that is
designed to look like the production or field environment, at least in those ways
which would affect response time and resource utilization and performance tests
need special tools to generate load and check response. So, performance test
environment acquisition and configuration is an activity in the test implementation
phase. You now estimate tasks involved in acquiring and configuring such a test
environment, such as simulating performance based on the production environment
design to look for potential bottlenecks, getting the right hardware, software and
tools and setting up hardware, software and tools.
Not everyone knows how to use performance-testing tools or to design perfor-
mance tests. So, performance-testing training or staffing is an activity in the test
planning phase. Depending on the approach you intend to take, you now estimate
the time required to identify and hire a performance test professional or to train one
or more people in your organization to do the job.
Finally, in many cases a detailed test plan is written for performance testing, due
to its differences from other test types. So, performance-testing planning is an
activity in the test planning phase. You now estimate the time required to draft,
review and finalize a performance test plan.
When you are creating your work-breakdown structure, remember that you
will want to use it for both estimation (at the beginning) and monitoring and control
(as the project continues). To ensure accuracy of the estimate and precise control,
make sure that you subdivide the work finely enough. This means that tasks should
be short in duration, say one to three days. If they are much longer
– say two
130
Chapter 5 Test management

weeks
– then you run the risk that long and complex sub-tasks are ‘hiding’ within
the larger task, only to be discovered later. This can lead to nasty surprises during
the project.
5.2.4 Estimation techniques
There are two techniques for estimation covered by the ISTQB Foundation Syllabus.
One involves consulting the people who will do the work and other people with
expertise on the tasks to be done. The other involves analyzing metrics from past
projects and from industry data. Let
’s look at each in turn.
Asking the individual contributors and experts involves working with experi-
enced staff members to develop a work-breakdown structure for the project. With
that done, you work together to understand, for each task, the effort, duration,
dependencies, and resource requirements. The idea is to draw on the collective
wisdom of the team to create your test estimate. Using a tool such as Microsoft
Project or a whiteboard and sticky-notes, you and the team can then predict the
testing end-date and major milestones. This technique is often called
‘bottom up’
estimation because you start at the lowest level of the hierarchical breakdown in the
work-breakdown structure
– the task – and let the duration, effort, dependencies and
resources for each task add up across all the tasks.
Analyzing metrics can be as simple or sophisticated as you make it. The simplest
approach is to ask,
‘How many testers do we typically have per developer on a
project?
’ A somewhat more reliable approach involves classifying the project in terms
of size (small, medium or large) and complexity (simple, moderate or complex) and
then seeing on average how long projects of a particular size and complexity
combination have taken in the past. Another simple and reliable approach we have
used is to look at the average effort per test case in similar past projects and to use the
estimated number of test cases to estimate the total effort. Sophisticated approaches
involve building mathematical models in a spreadsheet that look at historical or
industry averages for certain key parameters
– number of tests run by tester per
day, number of defects found by tester per day, etc.
– and then plugging in those
parameters to predict duration and effort for key tasks or activities on your project.
The tester-to-developer ratio is an example of a top-down estimation technique, in
that the entire estimate is derived at the project level, while the parametric technique
is bottom-up, at least when it is used to estimate individual tasks or activities.
We prefer to start by drawing on the team
’s wisdom to create the work-
breakdown structure and a detailed bottom-up estimate. We then apply models
and rules of thumb to check and adjust the estimate bottom-up and top-down using
past history. This approach tends to create an estimate that is both more accurate and
more defensible than either technique by itself.
Even the best estimate must be negotiated with management. Negotiating ses-
sions exhibit amazing variety, depending on the people involved. However, there are
some classic negotiating positions. It
’s not unusual for the test leader or manager to
try to sell the management team on the value added by the testing or to alert
management to the potential problems that would result from not testing enough.
It
’s not unusual for management to look for smart ways to accelerate the schedule or
to press for equivalent coverage in less time or with fewer resources. In between
these positions, you and your colleagues can reach compromise, if the parties are
willing. Our experience has been that successful negotiations about estimates are
those where the focus is less on winning and losing and more about figuring out how
Section 2 Test Planning and Estimation 131

best to balance competing pressures in the realms of quality, schedule, budget and
features.
5.2.5 Factors affecting test effort
Testing is a complex endeavour on many projects and a variety of factors can
influence it. When creating test plans and estimating the testing effort and schedule,
you must keep these factors in mind or your plans and estimates will deceive you at
the beginning of the project and betray you at the middle or end.
The test strategies or approaches you pick will have a major influence on the
testing effort. This factor is so influential that we
’ll come back to it in Section 5.2.6.
In this section, let
’s look at factors related to the product, the process and the results
of testing.
Product factors start with the presence of sufficient project documentation so that
the testers can figure out what the system is, how it is supposed to work and what
correct behaviour looks like. In other words, adequate and high-quality information
about the test basis will help us do a better, more efficient job of defining the tests.
The importance of non-functional quality characteristics such as usability, relia-
bility, security, performance, and so forth also influences the testing effort. These
test targets can be expensive and time consuming.
Complexity is another major product factor. Examples of complexity considera-
tions include:
l
The difficulty of comprehending and correctly handling the problem the system
is being built to solve (e.g. avionics and oil exploration software).
l
The use of innovative technologies, especially those long on hyperbole and short
on proven track records.
l
The need for intricate and perhaps multiple test configurations, especially when
these rely on the timely arrival of scarce software, hardware and other supplies.
l
The prevalence of stringent security rules, strictly regimented processes or other
regulations.
l
The geographical distribution of the team, especially if the team crosses time-
zones (as many outsourcing efforts do).
While good project documentation is a positive factor, it
’s also true that having to
produce detailed documentation, such as meticulously specified test cases, results in
delays. During test execution, having to maintain such detailed documentation
requires lots of effort, as does working with fragile test data that must be maintained
or restored frequently during testing.
Finally, increasing the size of the product leads to increases in the size of the
project and the project team. Increases in the project and project team increases the
difficulty of predicting and managing them. This leads to the disproportionate rate of
collapse of large projects.
Process factors include the availability of test tools, especially those that reduce
the effort associated with test execution, which is on the critical path for release. On
the development side, debugging tools and a dedicated debugging environment
(as opposed to debugging in the test environment) also reduce the time required to
complete testing.
The life cycle itself is an influential process factor, as the V-model tends to be
more fragile in the face of late change while incremental models tend to have high
132
Chapter 5 Test management

regression testing costs. Process maturity, including test process maturity, is another
factor, especially the implication that mature processes involve carefully managing
change in the middle and end of the project, which reduces test execution cost.
Time pressure is another factor to be considered. Pressure should not be an
excuse to take unwarranted risks. However, it is a reason to make careful, consid-
ered decisions and to plan and re-plan intelligently throughout the process, which is
another hallmark of mature processes.
People execute the process, and people factors are as important or more impor-
tant than any other. Indeed, even when many troubling things are true about a
project, an excellent team can often make good things happen on the project and in
testing. Important people factors include the skills of the individuals and the team as
a whole, and the alignment of those skills with the project
’s needs. Since a project
team is a team, solid relationships, reliable execution of agreed-upon commitments
and responsibilities and a determination to work together towards a common goal
are important. This is especially important for testing, where so much of what we
test, use, and produce either comes from, relies upon or goes to people outside the
testing group. Because of the importance of trusting relationships and the lengthy
learning curves involved in software and system engineering, the stability of the
project team is an important people factor, too.
The test results themselves are important in the total amount of test effort during
test execution. The delivery of good-quality software at the start of test execution
and quick, solid defect fixes during test execution prevents delays in the test
execution process. A defect, once identified, should not have to go through multiple
cycles of fix/retest/re-open, at least not if the initial estimate is going to be held to.
You probably noticed from this list that we included a number of factors outside
the scope and control of the test leader or manager. Indeed, events that occur before
or after testing can bring these factors about. For this reason, it
’s important that
testers, especially test leaders or managers, be attuned to the overall context in which
they operate. Some of these contextual factors result in specific project risks for
testing, which should be addressed in the test plan. Project risks are discussed in
more detail in Section 5.5.
5.2.6 Test approaches and strategies
A test strategy is the general way in which testing will happen, within each of the
levels of testing, independent of project, across the organization. The test approach
is the name the ISTQB gives to the implementation of the test strategy on a specific
project. Since the test approach is specific to a project, you should define and
document the approach in the test plans, and refine and document the test approach,
providing further details, in the test designs.
Deciding on the test approach involves careful consideration of the testing
objectives, the project
’s goals, and overall risk assessment. These decisions provide
the starting point for planning the test process, for selecting the test design techni-
ques and test types to be applied, and for defining the entry and exit criteria. In your
decision-making on the approach, you should take into account the project, product,
and organization context, issues related to risks, hazards and safety, the available
resources, the team
’s level of skills, the technology involved, the nature of the
system under test, considerations related to whether the system is custom built or
assembled from commercial off the shelf components (COTS), the organization
’s
test objectives, and any applicable regulations.
Section 2 Test Planning and Estimation 133

The choice of test approaches or strategies is one powerful factor in the success
of the test effort and the accuracy of the test plans and estimates. This factor is under
the control of the testers and test leaders. Of course, having choices also means that
you can make mistakes, so we
’ll go into more detail about how to pick the right test
strategies in a minute. First, though, let
’s survey the major types of test strategies
that are commonly found.
1
l
Analytical: For example, the risk-based strategy involves performing a risk
analysis using project documents and stakeholder input, then planning,
estimating, designing, and prioritizing the tests based on risk. (We
’ll talk
more about risk analysis later in this chapter.) Another analytical test strategy
is the requirements-based strategy, where an analysis of the requirements
specification forms the basis for planning, estimating and designing tests.
Analytical test strategies have in common the use of some formal or informal
analytical technique, usually during the requirements and design stages of
the project.
l
Model-based: For example, you can build mathematical models for loading
and response for e-commerce servers, and test based on that model. If the
behaviour of the system under test conforms to that predicted by the model,
the system is deemed to be working. Model-based test strategies have in common
the creation or selection of some formal or informal model for critical system
behaviours, usually during the requirements and design stages of the project.
l
Methodical: For example, you might have a checklist that you have put
together over the years that suggests the major areas of testing to run or you
might follow an industry-standard for software quality, such as ISO 9126, for
your outline of major test areas. You then methodically design, implement and
execute tests following this outline. Methodical test strategies have in common
the adherence to a pre-planned, systematized approach that has been developed
in-house, assembled from various concepts developed in-house and gathered
from outside, or adapted significantly from outside ideas and may have an
early or late point of involvement for testing.
l
Process- or standard-compliant: For example, you might adopt the IEEE 829
standard for your testing, using books such as [Craig and Jaskiel 2002] or
[Drabick 2004] to fill in the methodological gaps. Alternatively, you might adopt
an agile methodology. Process- or standard-compliant strategies have in common
reliance upon an externally developed approach to testing, often with little
– if
any
– customization and may have an early or late point of involvement for testing.
l
Dynamic: For example, you might create a lightweight set of testing guidelines
that focus on rapid adaptation or known weaknesses in software. Dynamic
strategies, such as exploratory testing, have in common concentrating on finding
as many defects as possible during test execution and adapting to the realities
of the system under test as it is when delivered, and they typically emphasize
the later stages of testing. See, for example, the attack-based approach of
[Whittaker 2002] and [Whittaker and Thompson 2003] and the exploratory
approach of [Kaner et al. 2002].
1
The catalogue of testing strategies that has been included in the ISTQB Foundation Syllabus grew out of
an email discussion between Rex Black, Ross Collard, Kathy Iberle and Cem Kaner. We thank them for
their thought-provoking comments.
134
Chapter 5 Test management

l
Consultative or directed: For example, you might ask the users or developers
of the system to tell you what to test or even rely on them to do the testing.
Consultative or directed strategies have in common the reliance on a group of
non-testers to guide or perform the testing effort and typically emphasize the
later stages of testing simply due to the lack of recognition of the value of
early testing.
l
Regression-averse: For example, you might try to automate all the tests of
system functionality so that, whenever anything changes, you can re-run
every test to ensure nothing has broken. Regression-averse strategies have in
common a set of procedures
– usually automated – that allow them to detect
regression defects. A regression-averse strategy may involve automating
functional tests prior to release of the function, in which case it requires
early testing, but sometimes the testing is almost entirely focused on testing
functions that already have been released, which is in some sense a form of
post-release test involvement.
Some of these strategies are more preventive, others more reactive. For
example, analytical test strategies involve upfront analysis of the test basis, and
tend to identify problems in the test basis prior to test execution. This allows
the early
– and cheap – removal of defects. That is a strength of preventive
approaches.
Dynamic test strategies focus on the test execution period. Such strategies allow
the location of defects and defect clusters that might have been hard to anticipate
until you have the actual system in front of you. That is a strength of reactive
approaches.
Rather than see the choice of strategies, particularly the preventive or reactive
strategies, as an either/or situation, we
’ll let you in on the worst-kept secret of testing
(and many other disciplines): There is no one best way. We suggest that you adopt
whatever test approaches make the most sense in your particular situation, and feel
free to borrow and blend.
How do you know which strategies to pick or blend for the best chance of
success? There are many factors to consider, but let us highlight a few of the most
important:
l
Risks: Testing is about risk management, so consider the risks and the level of
risk. For a well-established application that is evolving slowly, regression is an
important risk, so regression-averse strategies make sense. For a new application,
a risk analysis may reveal different risks if you pick a risk-based analytical
strategy.
l
Skills: Strategies must not only be chosen, they must also be executed. So, you
have to consider which skills your testers possess and lack. A standard-compliant
strategy is a smart choice when you lack the time and skills in your team to create
your own approach.
l
Objectives: Testing must satisfy the needs of stakeholders to be successful.
If the objective is to find as many defects as possible with a minimal amount
of up-front time and effort invested
– for example, at a typical independent
test lab
– then a dynamic strategy makes sense.
l
Regulations: Sometimes you must satisfy not only stakeholders, but also
regulators. In this case, you may need to devise a methodical test strategy that
satisfies these regulators that you have met all their requirements.
Section 2 Test Planning and Estimation 135

l
Product: Some products such as weapons systems and contract-development
software tend to have well-specified requirements. This leads to synergy with a
requirements-based analytical strategy.
l
Business: Business considerations and business continuity are often important. If
you can use a legacy system as a model for a new system, you can use a model-
based strategy.
We mentioned above that a good team can sometimes triumph over a situation
where materials, process and delaying factors are ranged against its success. How-
ever, talented execution of an unwise strategy is the equivalent of going very fast
down a highway in the wrong direction. Therefore, you must make smart choices in
terms of testing strategies. Furthermore, you must choose testing strategies with an
eye towards the factors mentioned earlier, the schedule, budget, and feature con-
straints of the project and the realities of the organization and its politics.
5 . 3
T E S T P R O G R E S S M O N I T O R I N G
A N D C O N T R O L
SYLLABUS LEARNING OBJECTIVES FOR 5.3 TEST
PROGRESS MONITORING AND CONTROL (K2)
LO-5.3.1 Recall common metrics used for monitoring test preparation
and execution. (K1)
LO-5.3.2 Explain and compare test metrics for test reporting and test
control (e.g. defects found and fixed, and tests passed and
failed) related to purpose and use. (K2)
LO-5.3.3 Summarize the purpose and content of the test summary
report document according to the ‘Standard for Software Test
Documentation’ (IEEE Std 829-1998). (K2)
In this section, we
’ll review techniques and metrics that are commonly used for
monitoring test preparation and execution. We
’ll focus especially on the use and
interpretation of such test metrics for reporting, controlling and analyzing the test
effort, including those based on defects and those based on test data. We
’ll also look
at options for reporting test status using such metrics and other information.
As you read, remember to watch for the glossary terms defect density and
failure rate.
5.3.1 Monitoring the progress of test activities
Having developed our plans, defined our test strategies and approaches and
estimated the work to be done, we must now track our testing work as we carry
it out. Test monitoring can serve various purposes during the project, including the
following:
l
Give the test team and the test manager feedback on how the testing work is
going, allowing opportunities to guide and improve the testing and the project.
136
Chapter 5 Test management

l
Provide the project team with visibility about the test results.
l
Measure the status of the testing, test coverage and test items against the exit
criteria to determine whether the test work is done.
l
Gather data for use in estimating future test efforts.
Especially for small projects, the test leader or a delegated person can gather test
progress monitoring information manually using documents, spreadsheets and sim-
ple databases. When working with large teams, distributed projects and long-term
test efforts, we find that the efficiency and consistency of data collection is aided by
the use of automated tools (see Chapter 6).
One way to gather test progress information is to use the IEEE 829 test log
template. While much of the information related to logging events can be usefully
captured in a document, we prefer to capture the test-by-test information in spread-
sheets (see Figure 5.1).
In Figure 5.1, columns A and B show the test ID and the test case or test suite
name. The state of the test case is shown in column C (
‘Warn’ indicates a test that
resulted in a minor failure). Column D shows the tested configuration, where the
codes A, B and C correspond to test environments described in detail in the test
plan. Columns E and F show the defect (or bug) ID number (from the defect-
tracking database) and the risk priority number of the defect (ranging from 1, the
worst, to 25, the least risky). Column G shows the initials of the tester who ran the
test. Columns H through L capture data for each test related to dates, effort and
duration (in hours). We have metrics for planned and actual effort and dates
completed which would allow us to summarize progress against the planned sche-
dule and budget. This spreadsheet can also be summarized in terms of the percen-
tage of tests which have been run and the percentage of tests which have passed and
failed.
Figure 5.1 might show a snapshot of test progress during the test execution
period, or perhaps even at test closure if it were deemed acceptable to skip
some of the tests. During the analysis, design and implementation of the tests,
such a worksheet would show the state of the tests in terms of their state of
development.
In addition to test case status, it is also common to monitor test progress during
the test execution period by looking at the number of defects found and fixed.
Figure 5.2 shows a graph that plots the total number of defects opened and closed
over the course of the test execution so far.
I E E E 8 2 9 S T A N D A R D: T E S T L O G T E M P L A T E
Test log identifier
Description (items being tested,
environment in which the testing is
conducted)
Activity and event entries (execution
description, procedure results,
environmental information,
anomalous events, incident report
identifiers)
Section 3 Test Progress Monitoring and Control 137

It also shows the planned test period end date and the planned number of defects
that will be found. Ideally, as the project approaches the planned end date, the total
number of defects opened will settle in at the predicted number and the total number
of defects closed will converge with the total number opened. These two outcomes
tell us that we have found enough defects to feel comfortable that we
’re done
testing, that we have no reason to think many more defects are lurking in the
product, and that all known defects have been resolved.
Charts such as Figure 5.2 can also be used to show failure rates or defect
density. When reliability is a key concern, we might be more concerned with the
frequency with which failures are observed than with how many defects are causing
the failures. In organizations that are looking to produce ultra-reliable software, they
may plot the number of unresolved defects normalized by the size of the product,
either in thousands of source lines of code (KSLOC), function points (FP) or some
other metric of code size. Once the number of unresolved defects falls below some
predefined threshold
– for example, three per million lines of code – then the
product may be deemed to have met the defect density exit criteria.
Measuring test progress based on defects found and fixed is common and useful
–
if used with care. Avoid using defect metrics alone, as it is possible to achieve a flat
defect find rate and to fix all the known defects by stopping any further testing, by
deliberately impeding the reporting of defects and by allowing programmers to reject,
cancel, or close defect reports without any independent review.
F I G U R E 5 . 1
Test case summary worksheet
failure rate The ratio of
the number of failures of
a given category to a
given unit of measure,
e.g. failures per unit of
time, failures per number
of transactions, failures
per number of computer
runs.
defect density The
number of defects
identified in a component
or system divided by the
size of the component or
system (expressed in
standard measurement
terms, e.g. lines-of-code,
number of classes or
function points).
138
Chapter 5 Test management

That said, test progress monitoring techniques vary considerably depending on
the preferences of the testers and stakeholders, the needs and goals of the project,
regulatory requirements, time and money constraints and other factors. In addition to
the kinds of information shown in the IEEE 829 Test Log Template, Figures 5.1 and
Figure 5.2, other common metrics for test progress monitoring include:
l
The extent of completion of test environment preparation.
l
The extent of test coverage achieved, measured against requirements, risks, code,
configurations or other areas of interest.
l
The status of the testing (including analysis, design and implementation)
compared to various test milestones.
l
The economics of testing, such as the costs and benefits of continuing test
execution in terms of finding the next defect or running the next test.
As a complementary monitoring technique, you might assess the subjective level
of confidence the testers have in the test items. However, avoid making important
decisions based on subjective assessments alone, as people
’s impressions have a
way of being inaccurate and coloured by bias.
5.3.2 Reporting test status
Test progress monitoring is about gathering detailed test data; reporting test status is
about effectively communicating our findings to other project stake-holders. As with
test progress monitoring, in practice there is wide variability observed in how people
report test status, with the variations driven by the preferences of the testers and
stakeholders, the needs and goals of the project, regulatory requirements, time and
money constraints and limitations of the tools available for test status reporting.
Integration and System Test Execution
System Quality Problems Analysis
10/7 10/21 11/4 11/18 12/2 12/16 12/30 1/13
1/27
2/10
2/24
3/10
250
0
500
750
1000
1250
1500
1750
2000
2250
2500
Exploratory testing yields
more-than-usual number
of bugs on most Fridays
Confirmation testing of fixed bugs in
each new release makes the total
closed curve jump on Mondays
and Tuesdays
Thanksgiving
Predicted number of bugs IST will
find by planned project end date, 3/21
Key Milestones
Total Opened
Integration Test Entry 10/7
System Test Entry 10/21
Integration Test Exit 2/14
System Test Exit 3/21
Total Closed
N.B. Closed counts include deferred bugs
Date Opened/Closed
F I G U R E 5 . 2
Total defects opened and closed chart
Section 3 Test Progress Monitoring and Control 139

Often variations or summaries of the metrics used for test progress monitoring, such
as Figure 5.1 and Figure 5.2, are used for test status reporting, too. Regardless of the
specific metrics, charts and reports used, test status reporting is about helping project
stakeholders understand the results of a test period, especially as it relates to key
project goals and whether (or when) exit criteria were satisfied.
In addition to notifying project stakeholders about test results, test status report-
ing is often about enlightening and influencing them. This involves analyzing the
information and metrics available to support conclusions, recommendations, and
decisions about how to guide the project forward or to take other actions. For
example, we might estimate the number of defects remaining to be discovered,
present the costs and benefits of delaying a release date to allow for further testing,
assess the remaining product and project risks and offer an opinion on the con-
fidence the stakeholders should have in the quality of the system under test.
You should think about test status reporting during the test planning and pre-
paration periods, since you will often need to collect specific metrics during and at
the end of a test period to generate the test status reports in an effective and efficient
fashion. The specific data you
’ll want to gather will depend on your specific reports,
but common considerations include the following:
l
How will you assess the adequacy of the test objectives for a given test level and
whether those objectives were achieved?
l
How will you assess the adequacy of the test approaches taken and whether they
support the achievement of the project
’s testing goals?
l
How will you assess the effectiveness of the testing with respect to these
objectives and approaches?
For example, if you are doing risk-based testing, one main test objective is to
subject the important product risks to the appropriate extent of testing. Table 5.1
shows an example of a chart that would allow you to report your test coverage and
unresolved defects against the main product risk areas you identified in your risk
analysis. If you are doing requirements-based testing, you could measure coverage
in terms of requirements or functional areas instead of risks.
On some projects, the test team must create a test summary report. Such a report,
created either at a key milestone or at the end of a test level, describes the results of a
given level or phase of testing. The IEEE 829 Standard Test Summary Report
Template provides a useful guideline for what goes into such a report. In addition
to including the kind of charts and tables shown earlier, you might discuss important
events (especially problematic ones) that occurred during testing, the objectives of
testing and whether they were achieved, the test strategy followed and how well it
worked, and the overall effectiveness of the test effort.
5.3.3 Test control
Projects do not always unfold as planned. In fact, any human endeavour more
complicated than a family picnic is likely to vary from plan. Risks become occur-
rences. Stakeholder needs evolve. The world around us changes. When plans and
reality diverge, we must act to bring the project back under control.
In some cases, the test findings themselves are behind the divergence; for
example, suppose the quality of the test items proves unacceptably bad and delays
test progress. In other cases, testing is affected by outside events; for example,
testing can be delayed when the test items show up late or the test environment is
140
Chapter 5 Test management

unavailable. Test control is about guiding and corrective actions to try to achieve the
best possible outcome for the project.
The specific corrective or guiding actions depend, of course, on what we are
trying to control. Consider the following hypothetical examples:
l
A portion of the software under test will be delivered late, after the planned
test start date. Market conditions dictate that we cannot change the release
date. Test control might involve re-prioritizing the tests so that we start testing
against what is available now.
l
For cost reasons, performance testing is normally run on weekday evenings
during off-hours in the production environment. Due to unanticipated high
demand for your products, the company has temporarily adopted an evening
shift that keeps the production environment in use 18 hours a day, five days
a week. Test control might involve rescheduling the performance tests for the
weekend.
T A B L E 5 . 1
Risk coverage by defects and tests
Unresolved defects
Test cases to be run
Test targets (product risk areas)
#
%
Planned
Actual
%
Performance, load, reliability
304
27
3843
1512
39
Robustness, operations, security
234
21
1032
432
42
Functionality, data, dates
224
20
4744
2043
43
Use cases, user interfaces, localization
160
14
498
318
64
Interfaces
93
8
193
153
79
Compatibility
71
6
1787
939
53
Other
21
2
0
0
0
1107
100
12857
5703
44
I E E E 8 2 9 S T A N D A R D: T E S T S U M M A R Y
R E P O R T T E M P L A T E
Test summary report identifier
Summary
Variances
Comprehensive assessment
Summary of results
Evaluation
Summary of activities
Approvals
Section 3 Test Progress Monitoring and Control 141

While these examples show test control actions that affect testing, the project
team might also have to take other actions that affect others on the project. For
example, suppose that the test completion date is at risk due to a high number of
defect fixes that fail confirmation testing in the test environment. In this case, test
control might involve requiring the programmers making the fixes to thoroughly
retest the fixes prior to checking them in to the code repository for inclusion in a
test build.
5 . 4
C O N F I G U R A T I O N M A N A GE M E N T
SYLLABUS LEARNING OBJECTIVES FOR 5.4
CONFIGURATION MANAGEMENT (K2)
LO-5.4.1 Summarize how configuration management supports
testing. (K2)
In this brief section, we
’ll look at how configuration management relates to and
supports testing. You will come across the glossary terms configuration control,
configuration management and version control.
Configuration management is a topic that often perplexes new practitioners,
but, if you ever have the bad luck to work as a tester on a project where this critical
activity is handled poorly, you
’ll never forget how important it is. Briefly put,
configuration management is in part about determining clearly what the items are
that make up the software or system. These items include source code, test scripts,
third-party software (including tools that support testing), hardware, data and both
development and test documentation. Configuration management is also about
making sure that these items are managed carefully, thoroughly and attentively
throughout the entire project and product life cycle.
Configuration management has a number of important implications for testing.
For one thing, it allows the testers to manage their testware and test results using the
same configuration management mechanisms, as if they were as valuable as the
source code and documentation for the system itself
– which of course they are.
For another thing, configuration management supports the build process, which
is essential for delivery of a test release into the test environment. Simply sending
Zip archives by e-mail will not suffice, because there are too many opportunities for
such archives to become polluted with undesirable contents or to harbour left-over
previous versions of items. Especially in later phases of testing, it is critical to have a
solid, reliable way of delivering test items that work and are the proper version.
Last but not least, configuration management allows us to map what is being tested
to the underlying files and components that make it up. This is absolutely critical. For
example, when we report defects, we need to report them against something, some-
thing which is configuration controlled or version controlled. If it’s not clear what
we found the defect in, the programmers will have a very tough time of finding the
defect in order to fix it. For the kind of test reports discussed earlier to have any
meaning, we must be able to trace the test results back to what exactly we tested.
Ideally, when testers receive an organized, version-controlled test release from a
change-managed source code repository, it is accompanied by a test item transmittal
report or release notes. [IEEE 829] provides a useful guideline for what goes into
configuration
management A
discipline applying
technical and
administrative direction
and surveillance to:
identify and document
the functional and
physical characteristics of
a configuration item,
control changes to those
characteristics, record
and report change
processing and
implementation status,
and verify compliance
with specified
requirements.
Configuration control
(version control) An
element of configuration
management, consisting
of the evaluation,
co-ordination, approval
or disapproval, and
implementation of
changes to configuration
items after formal
establishment of their
configuration
identification.
142
Chapter 5 Test management

such a report. Release notes are not always so formal and do not always contain all
the information shown.
While our description was brief, configuration management is a topic that is as
complex as test environment management. So, advanced planning is critical to
making this work. During the project planning stage
– and perhaps as part of your
own test plan
– make sure that configuration management procedures and tools are
selected. As the project proceeds, the configuration process and mechanisms must
be implemented, and the key interfaces to the rest of the development process
should be documented. Come test execution time, this will allow you and the rest
of the project team to avoid nasty surprises like testing the wrong software, receiv-
ing uninstallable builds and reporting irreproducible defects against versions of code
that don
’t exist anywhere but in the test environment.
5 . 5
R I S K A N D T E S T I N G
SYLLABUS LEARNING OBJECTIVES FOR 5 .5 RISK AND
TESTING (K2)
LO-5.5.1 Describe a risk as a possible problem that would threaten the
achievement of one or more stakeholders’ project
objectives. (K2)
LO-5.5.2 Remember that the level of risk is determined by likelihood
(of happening) and impact (harm resulting if it does
happen). (K1)
LO-5.5.3 Distinguish between the project and product risks. (K2)
LO-5.5.4 Recognize typical product and project risks. (K1)
LO-5.5.5 Describe, using examples, how risk analysis and risk
management may be used for test planning. (K2)
This section covers a topic that we believe is critical to testing: risk. Let
’s look
closely at risks, the possible problems that might endanger the objectives of the
project stakeholders. We
’ll discuss how to determine the level of risk using like-
lihood and impact. We
’ll see that there are risks related to the product and risks
related to the project, and look at typical risks in both categories. Finally
– and most
I E E E 8 2 9 S T A N D A R D : T E S T I T E M
T R A N S M I T T A L R E P O R T T E M P L A T E
Transmittal report identifier
Transmitted items
Location
Status
Approvals
Section 5 Risk and Testing 143

important
– we’ll look at various ways that risk analysis and risk management can
help us plot a course for solid testing
As you read this section, make sure to attend carefully to the glossary terms
product risk, project risk, and risk-based testing.
5.5.1 Risks and levels of risk
Risk is a word we all use loosely, but what exactly is risk? Simply put, it
’s the
possibility of a negative or undesirable outcome. In the future, a risk has some
likelihood between 0% and 100%; it is a possibility, not a certainty. In the past,
however, either the risk has materialized and become an outcome or issue or it has
not; the likelihood of a risk in the past is either 0% or 100%.
The likelihood of a risk becoming an outcome is one factor to consider when
thinking about the level of risk associated with its possible negative consequences.
The more likely the outcome is, the worse the risk. However, likelihood is not the
only consideration.
For example, most people are likely to catch a cold in the course of their lives,
usually more than once. The typical healthy individual suffers no serious conse-
quences. Therefore, the overall level of risk associated with colds is low for this
person. But the risk of a cold for an elderly person with breathing difficulties would
be high. The potential consequences or impact is an important consideration affect-
ing the level of risk, too.
Remember that in Chapter 1 we discussed how system context, and especially
the risk associated with failures, influences testing. Here, we
’ll get into more
detail about the concept of risks, how they influence testing, and specific ways to
manage risk.
We can classify risks into project risks (factors relating to the way the work is
carried out, i.e. the test project) and product risks (factors relating to what is produced
by the work, i.e. the thing we are testing). We will look at product risks first.
5.5.2 Product risks
You can think of a product risk as the possibility that the system or software
might fail to satisfy some reasonable customer, user, or stakeholder expectation.
(Some authors refer to
‘product risks’ as ‘quality risks’ as they are risks to the
quality of the product.) Unsatisfactory software might omit some key function that
the customers specified, the users required or the stakeholders were promised.
Unsatisfactory software might be unreliable and frequently fail to behave normally.
Unsatisfactory software might fail in ways that cause financial or other damage to a
user or the company that user works for. Unsatisfactory software might have
problems with data integrity and data quality, such as data migration issues, data
conversion problems, data transport problems, and violations of data standards
such as field and referential integrity. Unsatisfactory software might have problems
related to a particular quality characteristic. The problems might not involve
functionality, but rather security, reliability, usability, maintainability or perfor-
mance. Generally, the software could fail to perform its intended functions,
dissatisfying users and customers.
Risk-based testing is the idea that we can organize our testing efforts in a
way that reduces the residual level of product risk when the system ships. Risk-
based testing uses risk to prioritize and emphasize the appropriate tests during test
product risk A risk
directly related to the test
object.
risk-based testing An
approach to testing to
reduce the level of
product risks and inform
stakeholders of their
status, starting in the
initial stages of a project.
It involves the
identification of product
risks and the use of risk
levels to guide the test
process.
144
Chapter 5 Test management

execution, but it
’s about more than that. Risk-based testing starts early in the project,
identifying risks to system quality and using that knowledge of risk to guide testing
planning, specification, preparation and execution. Risk-based testing involves both
mitigation
– testing to provide opportunities to reduce the likelihood of defects,
especially high-impact defects
– and contingency – testing to identify work-arounds
to make the defects that do get past us less painful. Risk-based testing also involves
measuring how well we are doing at finding and removing defects in critical areas,
as was shown in Table 5.1. Risk-based testing can also involve using risk analysis to
identify proactive opportunities to remove or prevent defects through non-testing
activities and to help us select which test activities to perform.
Mature test organizations use testing to reduce the risk associated with delivering
the software to an acceptable level [Beizer 1990], [Hetzel 1988]. In the middle of the
1990s, a number of testers, including us, started to explore various techniques for
risk-based testing. In doing so, we adapted well-accepted risk management concepts
to software testing. Applying and refining risk assessment and management techni-
ques are discussed in [Black 2001] and [Black 2004]. For two alternative views, see
Chapter 11 of [Pol et al. 2002] and Chapter 2 of [Craig and Jaskiel 2002]. The origin
of the risk-based testing concept can be found in Chapter 1 of [Beizer 1990] and
Chapter 2 of [Hetzel 1988].
Risk-based testing starts with product risk analysis. One technique for risk
analysis is a close reading of the requirements specification, design specifications,
user documentation and other items. Another technique is brainstorming with many
of the project stakeholders. Another is a sequence of one-on-one or small-group
sessions with the business and technology experts in the company. Some people use
all these techniques when they can. To us, a team-based approach that involves the
key stakeholders and experts is preferable to a purely document-based approach, as
team approaches draw on the knowledge, wisdom and insight of the entire team to
determine what to test and how much.
While you could perform the risk analysis by asking,
‘What should we worry
about?
’ usually more structure is required to avoid missing things. One way to
provide that structure is to look for specific risks in particular product risk
categories. You could consider risks in the areas of functionality, localization,
usability, reliability, performance and supportability. Alternatively, you could use
the quality characteristics and sub-characteristics from ISO 9126 (introduced in
Chapter 1), as each sub-characteristic that matters is subject to risks that the
system might have troubles in that area. You might have a checklist of typical
or past risks that should be considered. You might also want to review the tests
that failed and the bugs that you found in a previous release or a similar product.
These lists and reflections serve to jog the memory, forcing you to think about
risks of particular kinds, as well as helping you structure the documentation of the
product risks.
When we talk about specific risks, we mean a particular kind of defect or failure
that might occur. For example, if you were testing the calculator utility that is bundled
with Microsoft Windows, you might identify
‘incorrect calculation’ as a specific risk
within the category of functionality. However, this is too broad. Consider incorrect
addition. This is a high-impact kind of defect, as everyone who uses the calculator
will see it. It is unlikely, since addition is not a complex algorithm. Contrast that with
an incorrect sine calculation. This is a low-impact kind of defect, since few people
use the sine function on the Windows calculator. It is more likely to have a defect,
though, since sine functions are hard to calculate.
Section 5 Risk and Testing 145

After identifying the risk items, you and, if applicable, the stakeholders, should
review the list to assign the likelihood of problems and the impact of problems
associated with each one. There are many ways to go about this assignment of
likelihood and impact. You can do this with all the stakeholders at once. You can
have the business people determine impact and the technical people determine
likelihood, and then merge the determinations. Either way, the reason for identifying
risks first and then assessing their level, is that the risks are relative to each other.
The scales used to rate likelihood and impact vary. Some people rate them high,
medium and low. Some use a 1
–10 scale. The problem with a 1–10 scale is that it’s
often difficult to tell a 2 from a 3 or a 7 from an 8, unless the differences between
each rating are clearly defined. A five-point scale (very high, high, medium, low and
very low) tends to work well.
Given two classifications of risk levels, likelihood and impact, we have a
problem, though: We need a single, aggregate risk rating to guide our testing effort.
As with rating scales, practices vary. One approach is to convert each risk classifi-
cation into a number and then either add or multiply the numbers to calculate a risk
priority number. For example, suppose a particular risk has a high likelihood and a
medium impact. The risk priority number would then be 6 (2 times 3).
Armed with a risk priority number, we can now decide on the various risk-
mitigation options available to us. Do we use formal training for programmers or
analysts, rely on cross-training and reviews or assume they know enough? Do we
perform extensive testing, cursory testing or no testing at all? Should we ensure unit
testing and system testing coverage of this risk? These options and more are
available to us.
As you go through this process, make sure you capture the key information in a
document. We
’re not fond of excessive documentation but this quantity of informa-
tion simply cannot be managed in your head. We recommend a lightweight table
like the one shown in Table 5.2; we usually capture this in a spreadsheet.
Let
’s finish this section with two quick tips about product risk analysis. First,
remember to consider both likelihood and impact. While it might make you feel like
a hero to find lots of defects, testing is also about building confidence in key
functions. We need to test the things that probably won
’t break but would be
catastrophic if they did.
Second, risk analyzes, especially early ones, are educated guesses. Make sure that
you follow up and revisit the risk analysis at key project milestones. For example, if
you
’re following a V-model, you might perform the initial analysis during the
T A B L E 5 . 2
A risk analysis template
Product risk
Likelihood
Impact
Risk priority #
Mitigation
Risk category 1
Risk 1
Risk 2
Risk n
146
Chapter 5 Test management

requirements phase, then review and revise it at the end of the design and imple-
mentation phases, as well as prior to starting unit test, integration test, and system
test. We also recommend revisiting the risk analysis during testing. You might find
you have discovered new risks or found that some risks weren
’t as risky as you
thought and increased your confidence in the risk analysis.
5.5.3 Project risks
We just discussed the use of testing to manage risks to product quality. However,
testing is an activity like the rest of the project and thus it is subject to risks that
endanger the project. To deal with the project risks that apply to testing, we can use
the same concepts we apply to identifying, prioritizing and managing product risks.
Remembering that a risk is the possibility of a negative outcome, what project
risks affect testing? There are direct risks such as the late delivery of the test items to
the test team or availability issues with the test environment. There are also indirect
risks such as excessive delays in repairing defects found in testing or problems with
getting professional system administration support for the test environment.
Of course, these are merely four examples of project risks; many others can apply
to your testing effort. To discover these risks, ask yourself and other project partici-
pants and stakeholders,
‘What could go wrong on the project to delay or invalidate the
test plan, the test strategy and the test estimate? What are unacceptable outcomes of
testing or in testing? What are the likelihoods and impacts of each of these risks?
’ You
can see that this process is very much like the risk analysis process for products.
Checklists and examples can help you identify test project risks [Black 2004].
For any risk, product or project, you have four typical options:
l
Mitigate: Take steps in advance to reduce the likelihood (and possibly the
impact) of the risk.
l
Contingency: Have a plan in place to reduce the impact should the risk become
an outcome.
l
Transfer: Convince some other member of the team or project stakeholder to
reduce the likelihood or accept the impact of the risk.
l
Ignore: Do nothing about the risk, which is usually a smart option only when
there
’s little that can be done or when the likelihood and impact are low.
There is another typical risk-management option, buying insurance, which is not
usually pursued for project or product risks on software projects, though it is not
unheard of.
Here are some typical risks along with some options for managing them:
l
Logistics or product quality problems that block tests: These can be mitigated
through careful planning, good defect triage and management, and robust test
design.
l
Test items that won
’t install in the test environment: These can be mitigated
through smoke (or acceptance) testing prior to starting test phases or as part of a
nightly build or continuous integration. Having a defined uninstall process is a
good contingency plan.
l
Excessive change to the product that invalidates test results or requires updates to
test cases, expected results and environments: These can be mitigated through
good change-control processes, robust test design and light-weight test
project risk A risk
related to management
and control of the (test)
project, e.g. lack of
staffing, strict deadlines,
changing requirements,
etc.
Section 5 Risk and Testing 147

documentation. When severe incidents occur, transference of the risk by
escalation to management is often in order.
l
Insufficient or unrealistic test environments that yield misleading results: One
option is to transfer the risks to management by explaining the limits on test
results obtained in limited environments. Mitigation
– sometimes complete
alleviation
– can be achieved by outsourcing tests such as performance tests that
are particularly sensitive to proper test environments.
Here are some additional risks to consider and perhaps to manage:
l
Organizational issues such as shortages of people, skills or training, problems
with communicating and responding to test results, bad expectations of what
testing can achieve and complexity of the project team or organization.
l
Supplier issues such as problems with underlying platforms or hardware, failure
to consider testing issues in the contract or failure to properly respond to the
issues when they arise.
l
Technical problems related to ambiguous, conflicting or unprioritized
requirements, an excessively large number of requirements given other project
constraints, high system complexity and quality problems with the design, the
code or the tests.
There may be other risks that apply to your project and not all projects are subject
to the same risks. See Chapter 2 of [Black 2009], Chapters 6 and 7 of [Black 2004]
and Chapter 3 of [Craig and Jaskiel 2002] for a discussion on managing project risks
during testing and in the test plan.
Finally, don
’t forget that test items can also have risks associated with them. For
example, there is a risk that the test plan will omit tests for a functional area or that
the test cases do not exercise the critical areas of the system.
5.5.4 Tying it all together for risk management
We can deal with test-related risks to the project and product by applying some
straightforward, structured risk management techniques. The first step is to assess or
analyze risks early in the project. Like a big ocean liner, projects, especially large
projects, require steering well before the iceberg is in plain sight. By using a test
plan template like the IEEE 829 template shown earlier, you can remind yourself to
consider and manage risks during the planning phase.
It
’s worth repeating here that early risk analyzes are educated guesses. Some of
those guesses will be wrong. Make sure that you plan to re-assess and adjust your
risks at regular intervals in the project and make appropriate course corrections to
the testing or the project itself.
One common problem people have when organizations first adopt risk-based
testing is a tendency to be excessively alarmed by some of the risks once they are
clearly articulated. Do not confuse impact with likelihood or vice versa. You should
manage risks appropriately, based on likelihood and impact. Triage the risks by
understanding how much of your overall effort can be spent dealing with them.
It
’s very important to maintain a sense of perspective, a focus on the point of the
exercise. As with life, the goal of risk-based testing should not be
– cannot
practically be
– a risk-free project. What we can accomplish with risk-based testing
is the marriage of testing with best practices in risk management to achieve a project
outcome that balances risks with quality, features, budget and schedule.
148
Chapter 5 Test management

5 . 6
I N C I D E N T M A N A G E M E N T
SYLLABUS LEARNING OBJECTIVES FOR 5 .6 INCIDENT
MANAGEMENT (K3)
LO-5.6.1 Recognize the content of an incident report according to the
‘Standard for Software Test Documentation’ (IEEE Std 829-
1998). (K1)
LO-5.6.2 Write an incident report covering the observation of a failure
during testing. (K3)
Let
’s wind down this chapter on test management with an important subject: how
we can document and manage the incidents that occur during testing. One of the
objectives of testing is to find defects, which reveal themselves as discrepancies
between actual and expected outcomes. These discrepancies are called anomalies.
When we observe an anomaly, we need to log the details as incidents. We have to
investigate these incidents, as some will be due to defects. Proper test management
involves establishing appropriate actions to investigate and dispose of incidents.
This includes tracking incidents (and any underlying defects) from initial discovery
and classification through to resolution, confirmation testing, and ultimate disposi-
tion, with the incidents following a clearly established set of rules and processes for
incident management and classification. We’ll look at what topics we should cover
when reporting incidents and defects. At the end of this section, you
’ll be ready to
write a thorough incident report.
Keep your eyes open for the Syllabus terms in this section, defect detection
percentage, defect report, incident logging, incident management, incident
report, priority, root cause and severity.
5.6.1 What are incident reports for and how do I write
good ones?
When running a test, you might observe actual results that vary from expected
results. This is not a bad thing
– one of the major goals of testing is to find problems.
Different organizations have different names to describe such situations. Com-
monly, they
’re called incidents, bugs, defects, problems or issues.
To be precise, we sometimes draw a distinction between incidents on the one
hand and defects or bugs on the other. An incident is any situation where the system
exhibits questionable behaviour, but often we refer to an incident as a defect only
when the root cause is some problem in the item we
’re testing.
Other causes of incidents include misconfiguration or failure of the test environ-
ment, corrupted test data, bad tests, invalid expected results and tester mistakes.
(However, in some cases the policy is to classify as a defect any incident that arises
from a test design, the test environment or anything else which is under formal
configuration management.) We talk about incidents to indicate the possibility that a
questionable behaviour is not necessarily a true defect. We log these incidents so
that we have a record of what we observed and can follow up the incident and track
what is done to correct it.
incident
management The
process of recognizing,
investigating, taking
action and disposing of
incidents. It involves
logging incidents,
classifying them and
identifying the impact.
Section 6 Incident Management 149

While it is most common to find incident logging or defect reporting processes
and tools in use during formal, independent test phases, you can also log, report,
track, and manage incidents found during development and reviews. In fact, this is a
good idea, because it gives useful information on the extent to which early
– and
cheaper
– defect detection and removal activities are happening.
Of course, we also need some way of reporting, tracking, and managing incidents
that occur in the field or after deployment of the system. While many of these
incidents will be user error or some other behaviour not related to a defect, some
percentage of defects do escape from quality assurance and testing activities. The
defect detection percentage, which compares field defects with test defects, is an
important metric of the effectiveness of the test process.
Here is an example of a DDP formula that would apply for calculating DDP for
the last level of testing prior to release to the field:
DDP
¼
defects
ðtestersÞ
defects
ðtestersÞ þ defects ðfieldÞ
It is most common to find defects reported against the code or the system itself.
However, we have also seen cases where defects are reported against requirements
and design specifications, user and operator guides and tests. Often, it aids the
effectiveness and efficiency of reporting, tracking and managing defects when the
defect-tracking tool provides an ability to vary some of the information captured
depending on what the defect was reported against.
In some projects, a very large number of defects are found. Even on smaller
projects where 100 or fewer defects are found, you can easily lose track of them
unless you have a process for reporting, classifying, assigning and managing the
defects from discovery to final resolution.
An incident report contains a description of the misbehaviour that was
observed and classification of that misbehaviour. As with any written communica-
tion, it helps to have clear goals in mind when writing. One common goal for such
reports is to provide programmers, managers and others with detailed information
about the behaviour observed and the defect. Another is to support the analysis of
trends in aggregate defect data, either for understanding more about a particular
set of problems or tests or for understanding and reporting the overall level of
system quality. Finally, defect reports, when analyzed over a project and even
across projects, give information that can lead to development and test process
improvements.
When writing an incident, it helps to have the readers in mind, too. The
programmers need the information in the report to find and fix the defects. Before
that happens, though, managers should review and prioritize the defects so that
scarce testing and developer resources are spent fixing and confirmation testing the
most important defects. Since some defects may be deferred
– perhaps to be fixed
later or perhaps, ultimately, not to be fixed at all
– we should include work-arounds
and other helpful information for help desk or technical support teams. Finally,
testers often need to know what their colleagues are finding so that they can watch
for similar behaviour elsewhere and avoid trying to run tests that will be blocked.
A good incident report is a technical document. In addition to being clear for its
goals and audience, any good report grows out of a careful approach to researching
and writing the report. We have some rules of thumb that can help you write a better
incident report.
incident logging
Recording the details of
any incident that occurred,
e.g. during testing.
Defect report (bug
report, problem
report) A document
reporting on any flaw in a
component or system
that can cause the
component or system to
fail to perform its
required function.
Defect detection
percentage (DDP) The
number of defects found
by a test phase, divided
by the number found by
that test phase and any
other means afterwards.
incident report A
document reporting on
any event that occurred,
e.g. during the testing,
which requires
investigation.
150
Chapter 5 Test management

First, use a careful, attentive approach to running your tests. You never know
when you
’re going to find a problem. If you’re pounding on the keyboard while
gossiping with office mates or daydreaming about a movie you just saw, you might
not notice strange behaviours. Even if you see the incident, how much do you really
know about it? What can you write in your incident report?
Intermittent or sporadic symptoms are a fact of life for some defects and it
’s
always discouraging to have an incident report bounced back as
‘irreproducible’. So,
it
’s a good idea to try to reproduce symptoms when you see them and we have found
three times to be a good rule of thumb. If a defect has intermittent symptoms, we
would still report it, but we would be sure to include as much information as
possible, especially how many times we tried to reproduce it and how many times
it did in fact occur.
You should also try to isolate the defect by making carefully chosen changes to
the steps used to reproduce it. In isolating the defect, you help guide the programmer
to the problematic part of the system. You also increase your own knowledge of
how the system works
– and how it fails.
Some test cases focus on boundary conditions, which may make it appear that a
defect is not likely to happen frequently in practice. We have found that it
’s a good
idea to look for more generalized conditions that cause the failure to occur, rather
than simply relying on the test case. This helps prevent the infamous incident report
rejoinder,
‘No real user is ever going to do that’. It also cuts down on the number of
duplicate reports that get filed.
As there is often a lot of testing going on with the system during a test period,
there are lots of other test results available. Comparing an observed problem against
other test results and known defects found is a good way to find and document
additional information that the programmer is likely to find very useful. For
example, you might check for similar symptoms observed with other defects, the
same symptom observed with defects that were fixed in previous versions or similar
(or different) results seen in tests that cover similar parts of the system.
Many readers of incident reports, managers especially, will need to understand
the priority and severity of the defect. So, the impact of the problem on the users,
customers and other stakeholders is important. Most defect-tracking systems have a
title or summary field and that field should mention the impact, too.
Choice of words definitely matters in incident reports. You should be clear and
unambiguous. You should also be neutral, fact-focused and impartial, keeping in
mind the testing-related interpersonal issues discussed in Chapter 1 and earlier in
this chapter. Finally, keeping the report concise helps keep people
’s attention and
avoids the problem of losing them in the details.
As a last rule of thumb for incident reports, we recommend that you use a review
process for all reports filed. It works if you have the lead tester review reports and
we have also allowed testers
– at least experienced ones – to review other testers’
reports. Reviews are proven quality assurance techniques and incident reports are
important project deliverables.
5.6.2 What goes in an incident report?
An incident report describes some situation, behaviour or event that occurred during
testing that requires further investigation. In many cases, an incident report consists
of one or two screens
– full of information gathered by a defect-tracking tool and
stored in a database.
priority The level of
(business) importance
assigned to an item, e.g.
defect.
severity The degree of
impact that a defect has
on the development or
operation of a
component or system.
Section 6 Incident Management 151

As mentioned above, you often document narrative information such as the
summary, the steps to reproduce, the isolation steps tried and the impact of the
problem. These fields should mention the inputs given and outputs observed,
the discrepancy or variance from expectations, the different ways you could
–
and couldn
’t – make the problem recur and the impact. Classification informa-
tion that a tester would provide includes the date and time of the failure, what
phase of the project the failure was found in, the test case that produced the
incident, references to specifications or other documents that provide informa-
tion about correct behaviour, the name of the tester (and perhaps the reviewer),
the test environment and any additional information about the configuration of
the software, system or environment. Sometimes testers classify the scope,
severity and priority of the defect, though sometimes managers or a bug triage
committee handle that role.
As the incident is managed to resolution, managers might assign a level of
priority to the report. The change control board or bug triage committee might
document the risks, costs, opportunities and benefits associated with fixing or not
fixing the defect. The programmer, when fixing the defect, can capture the root
cause, the phase of introduction and the phase of removal.
After the defect has been resolved, managers, programmers or others may want
to capture conclusions and recommendations. Throughout the life cycle of the
incident report, from discovery to resolution, the defect-tracking system should
allow each person who works on the incident report to enter status and history
information. IEEE 829 gives a template for test incident reports.
5.6.3 What happens to incident reports after you file them?
As we mentioned earlier, incident reports are managed through a life cycle from
discovery to resolution. The incident report life cycle is often shown as a state
transition diagram (see Figure 5.3). While your defect-tracking system may use a
different life cycle, let
’s take this one as an example to illustrate how an incident
report life cycle might work.
In the incident report life cycle shown in Figure 5.3, all incident reports move
through a series of clearly identified states after being reported. Some of these state
transitions occur when a member of the project team completes some assigned task
related to closing an incident report. Some of these state transitions occur when the
project team decides not to repair a defect during this project, leading to the deferral
of the incident report. Some of these state transitions occur when an incident report
I EE E 8 2 9 S T A N D A R D: T E S T I N C I DE N T
R E P O R T T E M P L A T E
Test incident report identifier
Summary
Incident description (inputs, expected
results, actual results, anomalies,
date and time, procedure step,
environment, attempts to repeat,
testers and observers)
Impact
root cause A source of a
defect such that if it is
removed, the occurrence
of the defect type is
decreased or removed.
152
Chapter 5 Test management

is poorly written or describes behaviour which is actually correct, leading to the
rejection of that report.
Let
’s focus on the path taken by incident reports which are ultimately fixed. After
an incident is reported, a peer tester or test manager reviews the report. If successful
in the review, the incident report becomes opened, so now the project team must
decide whether or not to repair the defect. If the defect is to be repaired, a
programmer is assigned to repair it.
Once the programmer believes the repairs are complete, the incident report
returns to the tester for confirmation testing. If the confirmation test fails, the
incident report is re-opened and then re-assigned. Once the tester confirms a good
repair, the incident report is closed. No further work remains to be done.
In any state other than rejected, deferred or closed, further work is required on
the incident prior to the end of this project. In such a state, the incident report has
a clearly identified owner. The owner is responsible for transitioning the incident
into an allowed subsequent state. The arrows in the diagram show these allowed
transitions.
In a rejected, deferred or closed state, the incident report will not be assigned
to an owner. However, certain real-world events can cause an incident report to
change state even if no active work is occurring on the incident report. Exam-
ples include the recurrence of a failure associated with a closed incident report
and the discovery of a more serious failure associated with a deferred incident
report.
Ideally, only the owner can transition the incident report from the current state
to the next state and ideally the owner can only transition the incident report to
an allowed next state. Most defect-tracking systems support and enforce the
life cycle and life cycle rules. Good defect-tracking systems allow you to
customize the set of states, the owners, and the transitions allowed to match
your actual workflows. And, while a good defect-tracking system is helpful,
the actual defect workflow should be monitored and supported by project and
company management.
Reported
Rejected
Deferred
Reopened
Closed
Opened
Assigned
Fixed
Reviewed
Confirmed
to be repaired
Bad report
Rewritten
Not a
problem
Declined
for repair
Failed
confirmation test
Approved for
re-repair
Approved
for repair
Repaired
Problem
returned
Gathered
new information
F I G U R E 5 . 3
Incident report life cycle
Section 6 Incident Management 153

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 5.1, you should now be able to explain the basic ideas of test
organization. You should know why independent testing is important, but also be
able to analyze the potential benefits and problems associated with independent test
teams. You should recognize the types of people and skills needed in a test team and
recall the tasks that a tester and a test leader will carry out. You should know the
glossary terms tester, test leader, test manager and test management.
From Section 5.2, you should now understand the fundamentals of test planning
and estimation. You should know the reasons for writing test plans and be able to
explain how test plans relate to projects, test levels or phases, test targets and test
execution. You should know which parts of the test process require special
attention in test planning. You should be able to explain the justification behind
various entry and exit criteria that might relate to projects, test levels or phases and
test targets. You should be able to distinguish the purpose and content of test plans
from that of test design specifications, test cases and test procedures, and know the
IEEE 829 outline for a test plan. You should know the factors that affect the effort
involved in testing, including especially test strategies (approaches) and how they
affect testing. You should be able to explain how metrics, expertise and negotia-
tion are used for estimating. There are no extra glossary terms for this section.
From Section 5.3, you should be able to explain the essentials of test progress
monitoring and control. You should know the common metrics that are captured,
logged and used for monitoring, as well as ways to present these metrics. You
should be able to analyze, interpret and explain test metrics that can be useful for
reporting test status and for making decisions about how to control test progress.
You should be able to explain a typical test status report and know the IEEE 829 test
summary report and test log. You should know the glossary terms defect density
and failure rate.
From Section 5.4, you should now understand the basics of configuration manage-
ment that relate to testing. You should be able to summarize how good configuration
management helps us do our testing work better. You should know the glossary terms
configuration control, configuration management and version control.
From Section 5.5, you should now be able to explain how risk and testing relate.
You should know that a risk is a potential undesirable or negative outcome and that
most of the risks we are interested in relate to the achievement of project objectives.
You should know about likelihood and impact as factors that determine the impor-
tance of a risk. You should be able to compare and contrast risks to the product (and
its quality) and risks to the project itself and know typical risks to the product and
project. You should be able to describe how to use risk analysis and risk manage-
ment for testing and test planning. You should know the glossary terms product
risk, project risk and risk-based testing.
From Section 5.6, you should now understand incident logging and be able to use
incident management on your projects. You should know the content of an incident
report according to the IEEE 829 standard. You should be able to write a high-
quality report based on test results and manage that report through its life cycle. You
should know the glossary terms defect detection percentage, defect report,
incident logging, incident management, incident report, priority, root cause
and severity.
154
Chapter 5 Test management

S A M P L E E X A M Q U E S T I O N S
Question 1 Why is independent testing important?
a. Independent testing is usually cheaper than testing
your own work.
b. Independent testing is more effective at finding
defects.
c. Independent testers should determine the processes
and methodologies used.
d. Independent testers are dispassionate about
whether the project succeeds or fails.
Question 2 Which of the following is among the
typical tasks of a test leader?
a. Develop system requirements, design
specifications and usage models.
b. Handle all test automation duties.
c. Keep tests and test coverage hidden from
programmers.
d. Gather and report test progress metrics.
Question 3 According to the ISTQB Glossary, what
do we mean when we call someone a test manager?
a. A test manager manages a collection of test
leaders.
b. A test manager is the leader of a test team or teams.
c. A test manager gets paid more than a test leader.
d. A test manager reports to a test leader.
Question 4 What is the primary difference between
the test plan, the test design specification, and the test
procedure specification?
a. The test plan describes one or more levels of
testing, the test design specification identifies the
associated high-level test cases and a test
procedure specification describes the actions for
executing a test.
b. The test plan is for managers, the test design
specification is for programmers and the test
procedure specification is for testers who are
automating tests.
c. The test plan is the least thorough, the test
procedure specification is the most thorough and
the test design specification is midway between
the two.
d. The test plan is finished in the first third of the
project, the test design specification is finished in
the middle third of the project and the test
procedure specification is finished in the last third
of the project.
Question 5 Which of the following factors is an
influence on the test effort involved in most projects?
a. Geographical separation of tester and
programmers.
b. The departure of the test manager during the
project.
c. The quality of the information used to develop the
tests.
d. Unexpected long-term illness by a member of the
project team.
Question 6 The ISTQB Foundation Syllabus
establishes a fundamental test process where test
planning occurs early in the project, while test
execution occurs later. Which of the following
elements of the test plan, while specified during test
planning, are assessed during test execution?
a. Test tasks
b. Environmental needs
c. Exit criteria
d. Test team training
Question 7 Consider the following exit criteria
which might be found in a test plan:
I.
No known customer-critical defects.
II.
All interfaces between components tested.
III.
100% code coverage of all units.
IV.
All specified requirements satisfied.
V.
System functionality matches legacy system for all
business rules.
Which of the following statements is true about
whether these exit criteria belong in an acceptance
test plan?
a. All statements belong in an acceptance test plan.
b. Only statement I belongs in an acceptance
test plan.
Sample Exam Questions 155

c. Only statements I, II, and V belong in an
acceptance test plan.
d. Only statements I, IV, and V belong in an
acceptance test plan.
Question 8 According to the ISTQB Glossary, what
is a test level?
a. A group of test activities that are organized
together.
b. One or more test design specification documents.
c. A test type.
d. An ISTQB certification.
Question 9 Which of the following metrics would
be most useful to monitor during test execution?
a. Percentage of test cases written.
b. Number of test environments remaining to be
configured.
c. Number of defects found and fixed.
d. Percentage of requirements for which a test has
been written.
Question 10 During test execution, the test manager
describes the following situation to the project team:
‘90% of the test cases have been run. 20% of the test
cases have identified defects. 127 defects have been
found. 112 defects have been fixed and have passed
confirmation testing. Of the remaining 15 defects,
project management has decided that they do not need
to be fixed prior to release.
’ Which of the following is
the most reasonable interpretation of this test status
report?
a. The remaining 15 defects should be confirmation
tested prior to release.
b. The remaining 10% of test cases should be run
prior to release.
c. The system is now ready for release with no further
testing or development effort.
d. The programmers should focus their attention on
fixing the remaining known defects prior to
release.
Question 11 In a test summary report, the project
’s
test leader makes the following statement,
‘The
payment processing subsystem fails to accept
payments from American Express cardholders, which
is considered a must-work feature for this release.
’
This statement is likely to be found in which of the
following sections?
a. Evaluation
b. Summary of activities
c. Variances
d. Incident description
Question 12 During an early period of test
execution, a defect is located, resolved and confirmed
as resolved by re-testing, but is seen again later during
subsequent test execution. Which of the following is a
testing-related aspect of configuration management
that is most likely to have broken down?
a. Traceability
b. Confirmation testing
c. Configuration control
d. Test documentation management
Question 13 You are working as a tester on a
project to develop a point-of-sales system for grocery
stores and other similar retail outlets. Which of the
following is a product risk for such a project?
a. The arrival of a more-reliable competing product
on the market.
b. Delivery of an incomplete test release to the first
cycle of system test.
c. An excessively high number of defect fixes fail
during re-testing.
d. Failure to accept allowed credit cards.
Question 14 A product risk analysis meeting is held
during the project planning period. Which of the
following determines the level of risk?
a. Difficulty of fixing related problems in code.
b. The harm that might result to the user.
c. The price for which the software is sold.
d. The technical staff in the meeting.
Question 15 You are writing a test plan using the
IEEE 829 template and are currently completing the
Risks and Contingencies section. Which of the
following is most likely to be listed as a project risk?
a. Unexpected illness of a key team member.
b. Excessively slow transaction-processing time.
156
Chapter 5 Test management

c. Data corruption under network congestion.
d. Failure to handle a key use case.
Question 16 You and the project stakeholders
develop a list of product risks and project risks during
the planning stage of a project. What else should you
do with those lists of risks during test planning?
a. Determine the extent of testing required for the
product risks and the mitigation and contingency
actions required for the project risks.
b. Obtain the resources needed to completely cover
each product risk with tests and transfer
responsibility for the project risks to the project
manager.
c. Execute sufficient tests for the product risks, based
on the likelihood and impact of each product risk
and execute mitigation actions for all project risks.
d. No further risk management action is required at
the test planning stage.
Question 17 According to the ISTQB Glossary, a
product risk is related to which of the following?
a. Control of the test project
b. The test object
c. A single test item
d. A potential negative outcome
Question 18 In an incident report, the tester makes
the following statement,
‘At this point, I expect to
receive an error message explaining the rejection of
this invalid input and asking me to enter a valid input.
Instead the system accepts the input, displays an
hourglass for between one and five seconds and
finally terminates abnormally, giving the message,
“Unexpected data type: 15. Click to continue”.’ This
statement is likely to be found in which of the
following sections of an IEEE 829 standard incident
report?
a. Summary
b. Impact
c. Item pass/fail criteria
d. Incident description
Question 19 According to the ISTQB Glossary,
what do we call a document that describes any event
that occurred during testing which requires further
investigation?
a. A bug report
b. A defect report
c. An incident report
d. A test summary report
Question 20 A product risk analysis is performed
during the planning stage of the test process. During
the execution stage of the test process, the test
manager directs the testers to classify each defect
report by the known product risk it relates to (or to
‘other’). Once a week, the test manager runs a report
that shows the percentage of defects related to each
known product risk and to unknown risks. What is
one possible use of such a report?
a. To identify new risks to system quality.
b. To locate defect clusters in product subsystems.
c. To check risk coverage by tests.
d. To measure exploratory testing.
Sample Exam Questions 157

E X E R C I S E : I N C I D E N T R E P O R T
Assume you are testing a maintenance release which will add a new supported model to a browser-based
application that allows car dealers to order custom-configured cars from the maker. You are working with a
selected number of dealers who are performing beta testing. When they find problems, they send you an e-mail
describing the failure. You use that e-mail to create an IEEE 829 compliant incident report in your incident
management system.
You receive the following e-mail from one of the dealers:
I entered an order for a Racinax 917X in midnight violet. During the upload, I got an
‘unexpected return
value
’ error message. I then checked the order and it was in the system. I think the Internet connection
might have gone down for a moment our cable television went blank at the same time and we use a cable
modem for Internet access.
Write an IEEE 829 compliant incident report based on this e-mail, and note any elements of such a report which
might not be available based on this e-mail alone.
Note that this scenario, including the name of the car model, is entirely fictitious.
158
Chapter 5 Test management

E X E R C I S E S O L U T I O N
Here is an example of an incident report:
This report addresses the inputs, the expected results, the actual results, the difference between the expected and
actual results (the anomalies), and the procedure steps in which the tester identified the unexpected results.
Here
’s some additional information needed to improve the report:
l
The failure needs to be reproduced at least two more times. By doing the failure replication in the test
environment, the tester will be able to control whether the Internet connection goes down during the order and
for how long the connection is down.
l
Is the problem in any way specific to the Racinax 917X model and/or the colour? Isolation of the failure is
needed, and then the report can be updated.
l
Is the problem in any way specific to a cable modem connection? We would guess not, but checking with
different types of connections (during the isolation and replication discussed above) would make sense. If it
proves independent of the type of connection, we would know that the problem is more general than just for
cable modems.
l
The incident report should also include information about the date and time of the test, the beta test
environment, and the name of the beta tester and the tester entering the defect.
Test incident report identifier: This would be assigned by the incident tracking tool.
Summary: System returns confusing error message if Internet connectivity is interrupted.
Incident description:
Steps to reproduce
1 Entered an order for a Racinax 917X in midnight violet.
2 During the order upload, the system displayed an ‘unexpected return value’ error message.
3 Verified that, in spite of the error message, the order was in the system.
Suspected cause Given that a brief interruption in the Internet connection (provided through a cable
modem) may have occurred during order transmission, the suspected cause of the failure is a lack of
robust handling of slow or unreliable Internet connections.
Impact assessment The message in step 2 is not helpful to the user, because it gives the user no clues
about what to do next. A user encountering the message described in step 2 might decide to re-enter
the order, which in this case would result in a redundant order.
Some car dealerships will have unreliable Internet connections, with the frequency of connection loss
depending on location, wireless infrastructure available in the dealership, type of Internet connection
hardware used in the dealers
’ computers, and other such factors. Therefore, we can expect that some
number of incidents such as this will occur in widespread use. (Indeed, this beta test incident proves
that this is a likely event in the real world.) Since a careless or rushed dealer might decide to resubmit
the order based on the error message, this will result in redundant orders, which will cause significant
loss of profitability for the dealerships and the salespeople themselves.
Exercise Solution 159

CHAPTER SIX
Tool support for testing
Y
ou may be wishing that you had a magic tool that would automate all of the
testing for you. If so, you will be disappointed. However, there are a number of
very useful tools that can bring significant benefits. In this chapter we will see that
there is tool support for many different aspects of software testing. We will see that
success with tools is not guaranteed, even if an appropriate tool is acquired
– there
are also risks in using tools. There are some special considerations mentioned in the
Syllabus for certain types of tool: test execution tools, performance testing tools,
static analysis tools and test management tools.
6 . 1
T Y P E S O F T E S T T O O L
SYLLABUS LEARNING OBJECTIVES FOR
6.1 TYPES OF TEST TOOL (K2)
LO-6.1.1 Classify different types of test tools according to their purpose
and to the activities of the fundamental test process and the
software life cycle. (K2)
LO-6.1.3 Explain the term test tool and the purpose of tool support for
testing. (K2)
(Please note that a learning objective, LO-6.1.2, was deleted in the 2010 release,
which results in the gap in numbering here.)
In this section, we will describe the various tool types in terms of their general
functionality, rather than going into lots of detail. The reason for this is that, in
general, the types of tool will be fairly stable over a longer period, even though there
will be new vendors in the market, new and improved tools, and even new types of
tool in the coming years.
We will not mention any commercial tools in this chapter. If we did, this book
would date very quickly! Tool vendors are acquired by other vendors, change their
names, and change the names of the tools quite frequently, so we will not mention
the names of any tools or vendors.
As we go through this section, watch for the Syllabus terms capture/playback
tool, configuration management tool, coverage tool, debugging tool, dynamic
analysis tool, incident management tool, load testing tool, modelling tool, mon-
itoring tool, performance testing tool, probe effect, requirements management
tool, review tool, security testing tool, security tool, static analysis tool, static code
160

analysis, static code analyzer, stress testing tool, test comparator, test compar-
ison, test data preparation tool, test design tool, test framework, test execution
tool, test management tool, unit test framework tool and volume testing. You’ll
find these terms defined in the glossary.
6.1.1 Understanding the Meaning and Purpose of Tool
Support for Testing
There are a number of ways in which tools can be used for testing, though most of
the time people think of automated test execution when they think of test tools.
What can tools do for us as testers?
1
To start with the most visible use, we can use tools directly in testing. This
includes test execution tools (including via so-called test frameworks), test data
generation tools and result comparison tools.
2
We can use tools to help us manage the testing process. This includes tools
that manage tests, test results, test data, requirements, incidents, and defects, as
well as tools that assist with reporting and monitoring test execution progress.
3
We can use tools as part of what
’s called reconnaissance, or, to use a simpler
term, exploration. For example, we can use tools to monitor file activity for an
application.
4
We can use tools in a number of other ways, in the form of any tool that aids
in testing. This would include spreadsheets when used to manage test assets or
progress, or as a way to document manual or automated tests.
What are we trying to achieve with tools? What are the motivations? As you can
imagine, these vary depending on the activity, but common objectives for the use of
tools include the following:
l
We might want to improve the efficiency of our testing. This can involve
automating repetitive tasks such as regression testing, or supporting manual
test activities such test planning, test design, test reporting and monitoring.
l
We might want to automate activities that would otherwise require significant
resources to do manually. Static testing of code, as discussed in Chapter 3, is
an example of this motivation.
l
We might need to carry out activities that simply cannot be done manually,
but which can be done via automated tools. Examples include large scale
performance testing of client-server or e-commerce applications.
l
We might want to increase the reliability of our testing. Examples include
automation of large data comparisons, simulating user behaviour, or repeating
large numbers of tests (which can lead to mistakes due to tedium of the work).
Clearly understanding the objectives for automation and tool support for testing is
essential for success, but so is a good business case, the right skills, and management
support.
6.1.2 Test tool classification
The tools are grouped by the testing activities or areas that are supported by a set of tools,
for example, tools that support management activities, tools to support static testing, etc.
test framework As
mentioned in the
Syllabus, the term
‘test
framework
’ is frequently
used in the software
testing profession.
However, it can have
three very distinct
meanings: 1) Reusable
and extensible testing
libraries that can be used
to build testing tools
(which are also called
test harnesses);
2) A type of design of
test automation
(e.g.,
data-driven and
keyword-driven); and,
3) An overall process of
execution of testing. In
the Foundation syllabus,
and in this book,
especially in this chapter,
we use the term
test
frameworks in its first
two meanings.
Section 1 Types of Test Tool 161

There is not necessarily a one-to-one relationship between a type of tool described
here and a tool offered by a commercial tool vendor or an open source tool. Some tools
perform a very specific and limited function (sometimes called a
‘point solution’), but
many of the commercial tools provide support for a number of different functions (tool
suites or families of tools). For example a
‘test management’ tool may provide support
for managing testing (progress monitoring), configuration management of testware,
incident management, and requirements management and traceability; another tool
may provide both coverage measurement and test design support.
There are some things that people can do much better or easier than a computer can
do. For example, when you see a friend in an unexpected place, say in an airport, you
can immediately recognize their face. This is an example of pattern recognition that
people are very good at, but it is not easy to write software that can recognize a face.
There are other things that computers can do much better or more quickly than
people can do. For example, can you add up 20 three-digit numbers quickly? This is
not easy for most people to do, so you are likely to make some mistakes even if the
numbers are written down. A computer does this accurately and very quickly. As
another example, if people are asked to do exactly the same task over and over, they
soon get bored and then start making mistakes.
The point is that it
’s a good idea to use computers to do things that computers are
really good at and that people are not very good at. So tool support is very useful for
repetitive tasks
– the computer doesn’t get bored and will be able to exactly repeat
what was done before. Because the tool will be fast, this can make those activities
much more efficient and more reliable. The tools can also do things that might
overload a person, such as comparing the contents of a large data file or simulating
how the system would behave.
A tool that measures some aspect of software may have unexpected side-effects on
that software. For example, a tool that measures timings for non-functional (performance)
testing needs to interact very closely with that software in order to measure it. A
performance tool will set a start time and a stop time for a given transaction in order to
measure the response time, for example. But the act of taking that measurement, i.e.
storing the time at those two points, could actually make the whole transaction take
slightly longer than it would do if the tool wasn
’t measuring the response time. Of course,
the extra time is very small, but it is still there. This effect is called the
‘probe effect’.
Another example of the probe effect occurs with coverage tools. In order to measure
coverage, the tool must first identify all of the structural elements that might be exercised
to see whether a test exercises it or not. This is called
‘instrumenting the code’. The tests
are then run through the instrumented code so that the tool can tell (through the
instrumentation) whether or not a given branch (for example) has been exercised. But
the instrumented code is not the same as the real code
– it also includes the instrumenta-
tion code. In theory the code is the same, but in practice, it isn
’t. Because different
coverage tools work in slightly different ways, you may get a slightly different coverage
measure on the same program because of the probe effect. For example different tools
may count branches in different ways, so the percentage of coverage would be compared
to a different total number of branches. The response time of the instrumented code may
also be significantly worse than the code without instrumentation. (There are also non-
intrusive coverage tools that observe the blocks of memory containing the object code to
get a rough measurement without instrumentation, e.g. for embedded software.)
One further example of the probe effect is when a debugging tool is used to try to
find a particular defect. If the code is run with the debugger, then the bug disappears;
it only reappears when the debugger is turned off (thereby making it much more
probe effect The effect
on the component or
system by the
measurement instrument
when the component or
system is being
measured, e.g. by a
performance testing tool
or monitor. For example
performance may be
slightly worse when
performance testing tools
are being used.
162
Chapter 6 Tool support for testing

difficult to find). These are sometimes known as
‘Heisenbugs’ (after Heisenberg’s
uncertainty principle).
In the descriptions of the tools below, we will indicate the tools that are more
likely to be used by developers during component testing and component integration
testing. For example coverage measurement tools are most often used in component
testing, but performance testing tools are more often used at system testing, system
integration testing and acceptance testing.
Note that for the Foundation Certificate exam, you only need to recognize the
different types of tools and what they do; you do not need a detailed understanding
of them (or know how to use them).
6.1.3 Tool support for management of testing and tests
What does
‘test management’ mean? It could be ‘the management of tests’ or it could
be
‘managing the testing process’. The tools in this broad category provide support for
either or both of these. The management of testing applies over the whole of the
software development life cycle, so a test management tool could be among the first to
be used in a project. A test management tool may also manage the tests, which would
begin early in the project and would then continue to be used throughout the project
and also after the system had been released. In practice, test management tools are
typically used by specialist testers or test managers at system or acceptance test level.
Test management tools
The features provided by test management tools include those listed below. Some
tools will provide all of these features; others may provide one or more of the
features, however such tools would still be classified as test management tools.
Features or characteristics of test management tools include support for:
l
management of tests or testware management (e.g. keeping track of the
associated data for a given set of tests, knowing which tests need to run in a
common environment, number of tests planned, written, run, passed or failed);
l
scheduling of tests to be executed (manually or by a test execution tool);
l
management of testing activities (time spent in test design, test execution,
whether we are on schedule or on budget);
l
interfaces to other tools, such as
– test execution tools (test running tools);
– incident management tools;
– requirement management tools;
– configuration management tools;
l
traceability of tests, test results and defects to requirements or other sources;
l
logging test results (note that the test management tool does not run tests, but
could summarize results from test execution tools that the test management tool
interfaces with);
l
preparing progress reports based on metrics (quantitative analysis), such as:
– tests run and tests passed;
– incidents raised, defects fixed and outstanding.
This information can be used to monitor the testing process and decide what actions
to take (test control), as described in Chapter 5. The tool also gives information about
Test management
tool A tool that provides
support to the test
management and control

tải về 6.34 Mb.

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