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

the component or system being tested (the test object). Test management tools help to
gather, organize, and communicate information about the testing on a project.
Requirements management tools
Are requirements management tools really testing tools? Some people may say they
are not, but they do provide some features that are very helpful to testing. Because tests
are based on requirements, the better the quality of the requirements, the easier it will be
to write tests from them. It is also important to be able to trace tests to requirements and
requirements to tests, as we saw in Chapter 2.
Some requirements management tools are able to find defects in the requirements,
for example by checking for ambiguous or forbidden words, such as
‘might’, ‘and/or’,
‘as needed’ or ‘(to be decided)’.
Features or characteristics of requirements management tools include support for:
l
storing requirement statements;
l
storing information about requirement attributes;
l
checking consistency of requirements;
l
identifying undefined, missing or
‘to be defined later’ requirements;
l
prioritizing requirements for testing purposes;
l
traceability of requirements to tests and tests to requirements, functions or
features;
l
traceability through levels of requirements;
l
interfacing to test management tools;
l
coverage of requirements by a set of tests (sometimes).
Incident management tools
This type of tool is also known as a defect-tracking tool, a defect-management
tool, a bug-tracking tool or a bug-management tool. However,
‘incident manage-
ment tool’ is probably a better name for it because not all of the things tracked are
actually defects or bugs; incidents may also be perceived problems, anomalies
(that aren
’t necessarily defects) or enhancement requests. Also what is normally
recorded is information about the failure (not the defect) that was generated during
testing
– information about the defect that caused that failure would come to light
when someone (e.g. a developer) begins to investigate the failure.
Incident reports go through a number of stages from initial identification and
recording of the details, through analysis, classification, assignment for fixing, fixed,
re-tested and closed, as described in Chapter 5. Incident management tools make it
much easier to keep track of the incidents over time.
Features or characteristics of incident management tools include support for:
l
storing information about the attributes of incidents (e.g. severity);
l
storing attachments (e.g. a screen shot);
l
prioritizing incidents;
l
assigning actions to people (fix, confirmation test, etc.);
l
status (e.g. open, rejected, duplicate, deferred, ready for confirmation test, closed);
l
reporting of statistics/metrics about incidents (e.g. average time open, number of
incidents with each status, total number raised, open or closed).
Requirements
management tool
A tool that supports the
recording of requirements,
requirements attributes
(e.g. priority, knowledge
responsible) and
annotation, and facilitates
traceability through layers
of requirements and
requirements change
management. Some
requirements
management tools also
provide facilities for static
analysis, such as
consistency checking and
violations to pre-defined
requirements rules.
Incident management
tool (defect
management tool)
A tool that facilitates the
recording and status
tracking of incidents.
They often have
workflow-oriented
facilities to track and
control the allocation,
correction and re-testing
of incidents and provide
reporting facilities.
164
Chapter 6 Tool support for testing
l storing requirement statements;
l storing information about requirement attributes;
l checking consistency of requirements;
l identifying undefined, missing or ‘to be defined later’ requirements;

Incident management tool functionality may be included in commercial test
management tools.
Configuration management tools
An example: A test group began testing the software, expecting to find the usual
fairly high number of problems. But to their surprise, the software seemed to be
much better than usual this time
– very few defects were found. Before they
celebrated the great quality of this release, they just made an additional check to
see if they had the right version and discovered that they were actually testing the
version from two months earlier (which had been debugged) with the tests for that
earlier version. It was nice to know that this was still OK, but they weren
’t actually
testing what they thought they were testing or what they should have been
testing.
Configuration management tools are not strictly testing tools either, but good
configuration management is critical for controlled testing, as was described in
Chapter 5. We need to know exactly what it is that we are supposed to test, such as
the exact version of all of the things that belong in a system. It is possible to
perform configuration management activities without the use of tools, but the tools
make life a lot easier, especially in complex environments.
Testware needs to be under configuration management and the same tool may be
able to be used for testware as well as for software items. Testware also has different
versions and is changed over time. It is important to run the correct version of the
tests as well, as our earlier example shows.
Features or characteristics of configuration management tools include support for:
l
storing information about versions and builds of the software and testware;
l
traceability between software and testware and different versions or variants;
l
keeping track of which versions belong with which configurations (e.g. operating
systems, libraries, browsers);
l
build and release management;
l
baselining (e.g. all the configuration items that make up a specific release);
l
access control (checking in and out).
6.1.4 Tool support for static testing
The tools described in this section support the testing activities described in Chapter 3.
Review tools
The value of different types of review was discussed in Chapter 3. For a very
informal review, where one person looks at another
’s document and gives a few
comments about it, a tool such as this might just get in the way. However, when the
review process is more formal, when many people are involved, or when the people
involved are in different geographical locations, then tool support becomes far more
beneficial.
It is possible to keep track of all the information for a review process using
spreadsheets and text documents, but a review tool that is designed for the purpose
is more likely to do a better job. For example, one thing that should be monitored
for each review is that the reviewers have not gone over the document too quickly,
i.e. that the checking rate (number of pages checked per hour) was close to that
Configuration
management tool
A tool that provides
support for the
identification and control
of configuration items,
their status over changes
and versions, and the
release of baselines
consisting of
configuration items.
Review tool A tool that
provides support to the
review process. Typical
features include review
planning and tracking
support, communication
support, collaborative
reviews and a repository
for collecting and
reporting of metrics.
Section 1 Types of Test Tool 165

recommended for that review cycle. A review tool could automatically calculate the
checking rate and flag exceptions. The review tools can normally be tailored for the

tải về 6.34 Mb.

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