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

approved, we go to payment (S4); if not, we go back to the shopping state (possibly to remove some items to
reduce the total price we have to pay). There are four states and seven transitions.
Note that S1 is our Start State for this example and S4 is the End State
– this means that we are not concerned
with any event that happens once we get to State S4.
Here is a test to cover all transitions. Note that the end state from one step or event is the start state for the next
event, so these steps must be done in this sequence.
State
Event (action)
S1
Add item
S2
Remove (last) item
S1
Add item
S2
Add item
S2
Remove item
S2
Check out
S3
Not OK
S2
Check out
S3
OK
S4
Although our example is not interested in what happens from State 4, there would be other events and actions
once we enter the payment process that could be shown by another state diagram (e.g. check validity of the credit
card, deduct the amount, email a receipt, etc.).
The corresponding state table is:
State or event
Add item
Remove item Remove last item
Check out
Not OK
OK
S1 Empty
S2
–
–
–
–
–
S2 Shopping
S2
S2
S1
S3
–
–
S3 Summary
–
–
–
–
S2
S4
S4 Payment
–
–
–
–
–
–
All of the boxes that contain
– are invalid transitions in this example. Example negative tests would include:
l
attempt to add an item from the summary and cost state (S3)
l
try to remove an item from the empty shopping basket (S1)
l
try to enter
‘OK’ while in the Shopping state (S2).
Statement and decision testing exercise
The control flow diagram is shown in Figure 4.8. Note that drawing a control diagram here illustrates that
structural testing can also be applied to the structure of general processes, not just to computer algorithms.
Flowcharts are generally easier to understand than text when you are trying to describe the results of decisions
taken on later events.
Exercise Solutions 119

On Figure 4.9, we can see the route that Tests 1 and 2 have taken through our control flow graph. Test 1 has
gone straight down the left-hand side to select a cold drink. Test 2 has gone to the right at each opportunity,
adding both milk and sugar to a hot drink.
Every statement (represented by a box on the diagram) has been covered by our two tests, so we have 100%
statement coverage.
We have not taken the No Exit from either the
‘milk?’ or ‘sugar?’ decisions, so there are two decision
outcomes that we have not tested yet. We did test both of the outcomes from the
‘hot or cold?’ decision, so we
have covered four out of six decision outcomes. Decision coverage is 4/6 or 67% with the two tests.
No additional tests are needed to achieve statement coverage, as we already have 100% coverage of the
statements.
One additional test is needed to achieve 100% decision coverage:
Test 3: Hot drink, no milk, no sugar
This test will cover both of the
‘No’ decision outcomes from the milk and sugar decisions, so we will now
have 100% decision coverage.
Hot or
cold?
milk?
Select
drink
(coffee, tea)
Select
drink
(H
2
O, cola)
Add milk
sugar?
Dispense drink
Hot
Cold
Y
N
N
Add sugar
Y
Test 1
Test 2
F I G U R E 4 . 9
Control flow diagram showing coverage
of tests
Hot or
cold?
milk?
Select
drink
(coffee, tea)
Select
drink
(H
2
O, cola)
Add milk
sugar?
Dispense drink
Hot
Cold
Y
N
N
Add sugar
Y
F I G U R E 4 . 8
Control flow diagram for drinks
dispenser
120
Chapter 4 Test design techniques

CHAPTER FIVE
Test management
T
esting is a complex activity. Testing is often a distinct sub-project within
the larger software development, maintenance, or integration project. Testing
usually accounts for a substantial proportion of the overall project budget.
Therefore, we must understand how we should manage the testing we do.
In this chapter, we cover essential topics for test management in six
sections. The first relates to how to organize the testers and the testing. The
second concerns the estimation, planning and strategizing of the test effort. The
third addresses test progress monitoring, test reporting and test control.
The fourth explains configuration management and its relationship to testing.
The fifth covers the central topic of risk and how testing affects and is affected
by product and project risks. The sixth and final section discusses the
management of incidents, both product defects and other events that require
further investigation.
5 . 1
T E S T O R G A N I Z A T I O N
SYLLABUS LEARNING OBJECTIVES FOR 5 .1 TEST
ORGANIZATION (K2)
LO-5.1.1 Recognize the importance of independent testing. (K1)
LO-5.1.2 Explain the benefits and drawbacks of independent testing
within an organization. (K2)
LO-5.1.3 Recognize the different team members to be considered for the
creation of a test team. (K1)
LO-5.1.4 Recall the tasks of typical test leader and tester. (K1)
In this section, let
’s talk about organizing a test effort within a project. We’ll
look at the value of independent testing, and discuss the potential benefits and
risks associated with independent testing. We will examine the various types of
different test team members we might want on a test team. And we
’ll familiarize
ourselves with the typical tasks performed by test leaders and testers.
As we go through this section, keep your eyes open for the glossary terms tester,
test leader, test manager and test management.
Test management The
planning, estimating,
monitoring and control
of test activities, typically
carried out by a test
manager.
121

5.1.1 Independent and integrated testing
In Chapter 1 we talked about independent testing from the perspective of individual
tester psychology. In this chapter, we’ll look at the organizational and managerial
implications of independence.
The approaches to organizing a test team vary, as do the places in the organiza-
tion structure where the test team fits. Since testing is an assessment of quality, and
since that assessment may not always be perceived as positive, many organizations
strive to create an organizational climate where testers can deliver an independent,
objective assessment of quality.
When thinking about how independent the test team is, recognize that indepen-
dence is not an either/or condition, but a continuum. At one end of the continuum
lies the absence of independence, where the programmer performs testing within the
programming team.
Moving toward independence, you find an integrated tester or group of testers
working alongside the programmers, but still within and reporting to the develop-
ment manager. You might find a team of testers who are independent and outside
the development team, but reporting to project management.
Near the other end of the continuum lies complete independence. You might see
a separate test team reporting into the organization at a point equal to the develop-
ment or project team. You might find specialists in the business domain (such as
users of the system), specialists in technology (such as database experts), and
specialists in testing (such as security testers, certification testers, or test automation
experts) in a separate test team, as part of a larger independent test team, or as part of
a contract, outsourced test team. Let
’s examine the potential benefits and risks of
independence, starting with the benefits.
An independent tester can often see more, other, and different defects than a
tester working within a programming team
– or a tester who is by profession a
programmer. While business analysts, marketing staff, designers, and programmers
bring their own assumptions to the specification and implementation of the item
under test, an independent tester brings a different set of assumptions to testing and
to reviews, which often helps expose hidden defects and problems related to the
group
’s way of thinking, as we discussed in Chapter 3. An independent tester brings
a sceptical attitude of professional pessimism, a sense that, if there
’s any doubt
about the observed behaviour, they should ask: Is this a defect?
At the team level, an independent test team reporting to a senior or executive
manager may enjoy (once they earn it) more credibility in the organization than a
test leader or tester who is part of the programming team. An independent tester
who reports to senior management may be able to report his results honestly and
without concern for reprisals that might result from pointing out problems in
co-workers
’ or, worse yet, the manager’s work. An independent test team often
has a separate budget, which helps ensure the proper level of money is spent on
tester training, testing tools, test equipment, and so forth. In addition, in some
organizations, testers in an independent test team may find it easier to have a career
path that leads up into more senior roles in testing.
Independent test teams are not risk-free. It
’s possible for the testers and the test
team to become isolated. This can take the form of interpersonal isolation from the
programmers, the designers, and the project team itself, or it can take the form of
isolation from the broader view of quality and the business objectives (e.g. obsessive
focus on defects, often accompanied by a refusal to accept business prioritization of
tester A skilled
professional who is
involved in the testing of
a component or system.
Test manager (test
leader) The person
responsible for project
management of testing
activities and resources,
and evaluation of a test
object. The individual
who directs, controls,
administers, plans and
regulates the evaluation
of a test object.
122
Chapter 5 Test management

defects). This leads to communication problems, feelings of alienation and antipa-
thy, a lack of identification with and support for the project goals, spontaneous
blame festivals and political backstabbing.
Even well-integrated test teams can suffer problems. Other project stake-holders
might come to see the independent test team
– rightly or wrongly – as a bottleneck
and a source of delay. Some programmers abdicate their responsibility for quality,
saying,
‘Well, we have this test team now, so why do I need to unit test my code?’
Due to a desire for the benefits of an independent test team, companies some-
times establish them, only to break them up again later. Why does that happen? A
common cause is the failure of the test manager to effectively manage the risks of
independence listed above. Some test teams succumb to the temptation to adopt a
‘no can do’ attitude, coming up with reasons why the project should bend to their
needs rather than each side being flexible so as to enable project success. Testers
take to acting as enforcers of process or as auditors without a proper management
mandate and support. Resentments and pressures build, until at last the organization
decides that the independent test team causes more problems than it solves. It
’s
especially important for testers and test managers to understand the mission they
serve and the reasons why the organization wants an independent test team. Often,
the entire test team must realize that, whether they are part of the project team or
independent, they exist to provide a service to the project team.
There is no one right approach to organizing testing. For each project, you must
consider whether to use an independent test team, based on the project, the applica-
tion domain, and the levels of risk, among other factors. As the size, complexity, and
criticality of the project increases, it is important to have independence in later levels
of testing (like integration test, system test and acceptance test), though some testing
is often best done by other people such as project managers, quality managers,
developers, business and domain experts or infrastructure or IT operations experts.
5.1.2 Working as a test leader
We have seen that the location of a test team within a project organization can vary
widely. Similarly there is wide variation in the roles that people within the test team
play. Some of these roles occur frequently, some infrequently. Two roles that are
found within many test teams are those of the test leader and the tester, though the
same people may play both roles at various points during the project. Let
’s take a
look at the work done in these roles, starting with the test leader.
Test leaders tend to be involved in the planning, monitoring, and control of the
testing activities and tasks discussed in Section 1.5 on the fundamental test process. At
the outset of the project, test leaders, in collaboration with the other stakeholders,
devise the test objectives, organizational test policies (if not already in place), test
strategies and test plans. They estimate the testing to be done and negotiate with
management to acquire the necessary resources. They recognize when test automation
is appropriate and, if it is, they plan the effort, select the tools, and ensure training of the
team. They may consult with other groups
– e.g. programmers – to help them with their
testing. They lead, guide and monitor the analysis, design, implementation and execu-
tion of the test cases, test procedures and test suites. They ensure proper configuration
management of the testware produced and traceability of the tests to the test basis.
As test execution comes near, they make sure the test environment is put into
place before test execution and managed during test execution. They schedule the
tests for execution and then they monitor, measure, control and report on the test
Section 1 Test Organization 123

progress, the product quality status and the test results, adapting the test plan and
compensating as needed to adjust to evolving conditions. During test execution and
as the project winds down, they write summary reports on test status.
Sometimes test leaders wear different titles, such as test manager or test coordi-
nator. Alternatively, the test leader role may wind up assigned to a project manager,
a development manager or a quality assurance manager. (Regarding the first two
people on this list, warning bells about independence should be ringing in your head
now, in addition to thoughts about how we can ensure that such non-testers gain the
knowledge and outlook needed to manage testing.) Whoever is playing the role,
expect them to plan, monitor and control the testing work.
5.1.3 Working as a tester
As with test leaders, projects should include testers at the outset, though more testers
may be required at later stages of testing. In the planning and preparation phases of
the testing, testers should review and contribute to test plans, as well as analyzing,
reviewing and assessing requirements and design specifications. They may be
involved in or even be the primary people identifying test conditions and creating
test designs, test cases, test procedure specifications and test data, and may automate
or help to automate the tests. They often set up the test environments or assist
system administration and network management staff in doing so.
As test execution begins, the number of testers often increases, starting with the
work required to implement tests in the test environment. (They may play such a
role on all test levels, even those not under the direct control of the test group; e.g.
they might implement unit tests which were designed by programmers.) Testers
execute and log the tests, evaluate the results and document problems found. They
monitor the testing and the test environment, often using tools for this task, and
often gather performance metrics. Throughout the testing life cycle, they review
each other
’s work, including test specifications, defect reports and test results.
5.1.4 Defining the skills test staff need
Doing testing properly requires more than defining the right positions and number of
people for those positions. Good test teams have the right mix of skills based on the
tasks and activities they need to carry out, and people outside the test team who are
in charge of test tasks need the right skills, too.
People involved in testing need basic professional and social qualifications such
as literacy, the ability to prepare and deliver written and verbal reports, the ability to
communicate effectively, and so on. Going beyond that, when we think of the skills
that testers need, three main areas come to mind:
l
Application or business domain: A tester must understand the intended behaviour,
the problem the system will solve, the process it will automate and so forth, in
order to spot improper behaviour while testing and recognize the
‘must work’
functions and features.
l
Technology: A tester must be aware of issues, limitations and capabilities of the
chosen implementation technology, in order to effectively and efficiently locate
problems and recognize the
‘likely to fail’ functions and features.
l
Testing: A tester must know the testing topics discussed in this book
– and often
more advanced testing topics
– in order to effectively and efficiently carry out the
test tasks assigned.
124
Chapter 5 Test management

The specific skills in each area and the level of skill required vary by project,
organization, application, and the risks involved.
The set of testing tasks and activities are many and varied, and so too are the
skills required, so we often see specialization of skills and separation of roles. For
example, due to the special knowledge required in the areas of testing, technology
and business domain, respectively, test automation experts may handle automating
the regression tests, programmers may perform component and integration tests and
users and operators may be involved in acceptance tests.
We have long advocated pervasive testing, the involvement of people through-
out the project team in carrying out testing tasks. Let us close this section, though,
on a cautionary note. Software and system companies (e.g. producers of shrink-
wrapped software and consumer products) typically overestimate the technology
knowledge required to be an effective tester. Businesses that use information
technology (e.g. banks and insurance companies) typically overestimate the busi-
ness domain knowledge needed.
All types of projects tend to underestimate the testing knowledge required. We
have seen a project fail in part because people without proper testing skills tested
critical components, leading to the disastrous discovery of fundamental architectural
problems later. Most projects can benefit from the participation of professional
testers, as amateur testing alone will usually not suffice.
5 . 2
T E S T P L A N N I N G A N D E S T I M A T I O N
SYLLABUS LEARNING OBJECTIVES FOR 5 .2 TEST
PLANNING AND ESTIMATION (K2)
LO-5.2.1 Recognize the different levels and objectives of test
planning. (K1)
LO-5.2.2 Summarize the purpose and content of the test plan, test
design specification and test procedure documents according
to the ‘Standard for Software Test Documentation’ (IEEE Std
829-1998). (K2)
LO-5.2.3 Differentiate between conceptually different test approaches,
such as analytical, model-based, methodical, process/standard
compliant, dynamic/heuristic, consultative and regression-
averse. (K2)
LO-5.2.4 Differentiate between the subject of test planning for a system
and scheduling test execution. (K2)
LO-5.2.5 Write a test execution schedule for a given set of test cases,
considering prioritization, and technical and logical
dependencies. (K3)
LO-5.2.6 List test preparation and execution activities that should be
considered during test planning. (K1)
Section 2 Test Planning and Estimation 125

LO-5.2.7 Recall typical factors that influence the effort related to
testing. (K1)
LO-5.2.8 Differentiate between two conceptually different estimation
approaches: the metrics-based approach and the expert-based
approach. (K2)
LO-5.2.9 Recognize/justify adequate entry and exit criteria for specific
test levels and groups of test cases (e.g. for integration testing,
acceptance testing or test cases for usability testing). (K2)
In this section, let
’s talk about a complicated trio of test topics: plans, estimates and
strategies. Plans, estimates and strategies depend on a number of factors, including
the level, targets and objectives of the testing we
’re setting out to do. Writing a plan,
preparing an estimate and selecting test strategies tend to happen concurrently and
ideally during the planning period for the overall project, though we must ready to
revise them as the project proceeds and we gain more information.
Let
’s look closely at how to prepare a test plan, examining issues related to
planning for a project, for a test level or phase, for a specific test type and for test
execution. We
’ll examine typical factors that influence the effort related to testing,
and see two different estimation approaches: metrics-based and expert-based. We
’ll
discuss selecting test strategies and ways to establish adequate exit criteria for
testing. In addition, we
’ll look at various tasks related to test preparation and
execution that need planning.
There are no extra glossary terms in this section.
5.2.1 The purpose and substance of test plans
While people tend to have different definitions of what goes in a test plan, for us a
test plan is the project plan for the testing work to be done. It is not a test design
specification, a collection of test cases or a set of test procedures; in fact, most of our
test plans do not address that level of detail.
Why do we write test plans? We have three main reasons.
First, writing a test plan guides our thinking. We find that if we can explain
something in words, we understand it. If not, there
’s a good chance we don’t. Writing
a test plan forces us to confront the challenges that await us and focus our thinking on
important topics. In Chapter 2 of Fred Brooks
’ brilliant and essential book on software
engineering management, The Mythical Man-Month, he explains the importance of
careful estimation and planning for testing as follows:
Failure to allow enough time for system test, in particular, is peculiarly
disastrous. Since the delay comes at the end of the schedule, no one is
aware of schedule trouble until almost the delivery date [and] delay at
this point has unusually severe
… financial repercussions. The project is
fully staffed, and cost-per-day is maximum [as are the associated
opportunity costs]. It is therefore very important to allow enough system
test time in the original schedule.
[Brooks 1995]
126
Chapter 5 Test management

We find that using a template when writing test plans helps us remember the
important challenges. You can use the IEEE 829 test plan template shown in this
chapter, use someone else
’s template, or create your own template over time.
The test planning process and the plan itself serve as vehicles for communicating
with other members of the project team, testers, peers, managers, and other stake-
holders. This communication allows the test plan to influence the project team and
the project team to influence the test plan, especially in the areas of organization-
wide testing policies and motivations; test scope, objectives, and critical areas to
test; project and product risks, resource considerations and constraints; and the
testability of the item under test.
You can accomplish this communication through circulation of one or two test
plan drafts and through review meetings. Such a draft may include many notes such
as the following examples:
[To Be Determined: Jennifer: Please tell me what the plan is for releasing
the test items into the test lab for each cycle of system test execution?]
[Dave
– please let me know which version of the test tool will be used for
the regression tests of the previous increments.]
As you document the answers to these kinds of questions, the test plan becomes a
record of previous discussions and agreements between the testers and the rest of the
project team.
The test plan also helps us manage change. During early phases of the project, as
we gather more information, we revise our plans. As the project evolves and situations
change, we adapt our plans. Written test plans give us a baseline against which to
measure such revisions and changes. Furthermore, updating the plan at major mile-
stones helps keep testing aligned with project needs. As we run the tests, we make
final adjustments to our plans based on the results. You might not have the time
– or
the energy
– to update your test plans every time a variance occurs, as some projects
can be quite dynamic. In Chapter 6 [Black 2009], we describe a simple approach for
documenting variances from the test plan that you can implement using a database or
spreadsheet. You can include these change records in a periodic test plan update, as

tải về 6.34 Mb.

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