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

Education