Test planning

Test Planning
 The
–

goal of a software tester is:

to find bugs, find them as early as possible, and
make sure they get fixed.

 Properly

communicating and documenting
the test effort with well-constructed test
plans, test cases, and test reports will make it
more likely that testers will achieve goal.

The Goal of Test Planning


If software testers don't communicate:
–
–
–




what plan to test,
what resources need, and
what your schedule is

Project will have little chance of succeeding.
The software test plan is the primary means by
which software testers communicate to the product
development team what they intend to do?

 IEEE

Standard 8291998 for Software Test
Documentation states:
–
–

To prescribe the scope, approach, resources, and
schedule of the testing activities.
To identify the items being tested, the features to
be tested, the testing tasks to be performed, the
personnel responsible for each task, and the risks
associated with the plan.

a test plan is required by law for reference and
archiving in some industries.
The ultimate goal of the test planning process is:


–



communicating (not recording) the software test team's
intent, its expectations, and its understanding of the testing
that's to be performed.

make sure that everyone has been informed and
understands what the test team is planning to do

Test Planning Topics
 High-Level
–
–
–
–

Expectations

What's the purpose of the test planning process
and the software test plan?
What product is being tested? Is it being
developed in house or by a third party?
There must be a complete understanding of what
the product is, its magnitude, and its scope.
What are the quality and reliability goals of the
product?



People, Places, and Things
–
–

–
–

Test planning needs to identify the people working on the
project, what they do, and how to contact them.
The test plan should include names, titles, addresses,
phone numbers, email addresses, and areas of
responsibility for all key people on the project.
Where documents are stored, where the software can be
downloaded from, where the test tools are located.
If hardware is necessary for running the tests, where is it
stored and how is it obtained? If there are external test labs
for configuration testing, where are they located and how
are they scheduled?



Definitions
–

–

–

–

Build. A compilation of code and content that the
programmers put together to be tested. The test plan
should define the frequency of builds (daily, weekly) and the
expected quality level.
Test release document (TRD). A document that the
programmers release with each build stating what's new,
different, fixed, and ready for testing.
Alpha release. A very early build intended for limited
distribution to a few key customers and to marketing for
demonstration purposes.
Beta release. The formal build intended for widespread
distribution to potential customers.

–
–

–

Spec complete. A schedule date when the specification is
supposedly complete and will no longer change.
Feature complete. A schedule date when the programmers
will stop adding new features to the code and concentrate
on fixing bugs.
Bug committee. A group made up of the test manager,
project manager, development manager, and product
support manager that meets weekly to review the bugs and
determine which ones to fix and how they should be fixed.

 Inter-Group
–

–

Responsibilities

Inter-group responsibilities identify tasks and
deliverables that potentially affect the test
effort.
The types of tasks that need to be defined
aren't the obvious ones testers test,
programmers program. The troublesome
tasks potentially have multiple owners or
sometimes no owner or a shared
responsibility.

table to help organize inter-group
responsibilities



What Will and Won't Be Tested
–
–
–
–

There may be components of the software that were
previously released and have already been tested.
An outsourcing company may supply pre-tested portions of
the product.
The planning process needs to identify each component of
the software and make known whether it will be tested.
If it's not tested, there needs to be a reason it won't be
covered.



Test Phases
–

–

–
–

To plan the test phases, the test team will look at the
proposed development model and decide whether unique
phases, or stages, of testing should be performed over the
course of the project.
In the waterfall and spiral models, there can be several test
phases from examining the product spec to acceptance
testing.
Test planning is one of the test phases.
The test planning process should identify each proposed
test phase and make each phase known to the project
team.

–

Two very important concepts associated with the test
phases are:
the entrance and
 exit criteria.
 Each phase must have criteria defined for it that objectively
and absolutely declares if the phase is over and the next one
has begun.


–

–

For example, the beta test stage might begin when the
testers have completed an acceptance test pass with no
new bugs found on the proposed beta release build.
Without explicit entrance and exit criteria, the test effort will
dissolve into single, undirected test effort much like the
code-and-fix development model.



Test Strategy
–
–

–

The test strategy describes the approach that the test team
will use to test the software both overall and in each phase.
It might be a good idea to test some of the code manually
and other code with tools and automation. If tools will be
used, do they need to be developed or can existing
commercial solutions be purchased? If so, which ones?
Maybe it would be more efficient to outsource the entire test
effort to a specialized testing company and require only a
skeleton testing crew to oversee their work.
Deciding on the strategy is a complex task one that needs
to be made by very experienced testers because it can
determine the success or failure of the test effort.



Resource Requirements
–
–
–
–
–
–

People. How many, what experience, what expertise?
Should they be full-time, part-time, contract, students?
Equipment. Computers, test hardware, printers, tools.
Office and lab space. Where will they be located? How big
will they be? How will they be arranged?
Software. Word processors, databases, custom tools.
What will be purchased, what needs to be written?
Outsource companies. Will they be used? What criteria
will be used for choosing them? How much will they cost?
Miscellaneous supplies. Disks, phones, reference books,
training material. What else might be necessary over the
course of the project?

 Tester
–

Assignments

Planning the tester assignments identifies the
testers responsible for each area of the software
and for each testable feature.



Test Schedule
–
–

–

The test schedule takes all the information presented so far
and maps it into the overall project schedule.
Completing a test schedule as part of test planning will
provide the product team and project manager with the
information needed to better schedule the overall project.
Based on the testing schedule, to cut certain features from
the product or postpone them to a later release.



Test Cases
–



The test planning process will decide what approach will be
used to write them, where the test cases will be stored, and
how they'll be used and maintained.

Bug Reporting
–

"Reporting What You Find," will describe the techniques
that can be used to record and track the bugs you find. The
possibilities range from shouting over a cubicle wall to
sticky notes to complex bug-tracking databases. Exactly
what process will be used to manage the bugs needs to be
planned so that each and every bug is tracked from when
it's found to when it's fixed and never, ever forgotten.



Metrics and Statistics
–
–

–

Metrics and statistics are the means by which the progress
and the success of the project, and the testing, are tracked.
"Measuring Your Success." The test planning process
should identify exactly what information will be gathered,
what decisions will be made with them, and who will be
responsible for collecting them.
Examples of test metrics are
Total bugs found daily over the course of the project
 List of bugs that still need to be fixed
 Current bugs ranked by how severe they are
 Total bugs found per tester
 Number of bugs found per software feature or area


 Risks
–

–

and Issues

To identify potential problem or risky areas of the
project ones that could have an impact on the test
effort.
As a software tester, you'll be responsible for
identifying risks during the planning process and
communicating your concerns to your manager
and the project manager.

Test planning

Related slideshows

Recommended for you

Recommended for you

Recommended for you

Recommended for you

Recommended for you

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Test planning

Similar to Test planning (20)

More from Abdul Basit

More from Abdul Basit (20)

Recently uploaded

Recently uploaded (20)

Test planning