A test plan is a document that answers the basic questions about your testing effort. It needs to be initiated during the requirements gathering phase of your project and should evolve into a roadmap for the testing phase. This is a non-trivial activity since without a solid test plan, testing activities tend to become ad-hoc, unscheduled single events and the only way to recognize when you are done testing is when you run out of time.
Test planning
enables a more reliable estimate of the testing effort up front
allows the project team time to consider ways to reduce the testing effort without being under time pressure
helps remove misunderstandings between developers and end-users before the solution is developed
creates a verifiable system component that will become part of the project documentation
helps to identify problem areas and focuses the testing team's attention on the critical paths
reduces the probability of implementing non-tested components
is an integral part of a coherent requirements management process
When should you plan testing activities?
Testing accounts for 45 - 75% of the typical project effort. It is also one of the most commonly underestimated activities on a project. We recommend that you plan your testing activities as early in the project as feasible and be ready to recognize when you have to change your plan.
Who should plan testing activities?
The responsibility for planning testing activities is different for unit, integration, and acceptance testing. You will need developers, managers, project leaders and end-users. If a quality assurance/testing group exists in your organization, involve them as early as they will allow you to.
Test Plans
Test
plans can exist on many different levels. You may have only one
overall test plan for the whole project or divide the overall
test plan further into test plans for unit testing, test plans
for acceptance testing, test plans for integration testing, etc.
But no matter how many test plans your organization uses on a
given project, each test plan should contain a set of activities
which define strategic and scheduling components.
Test Plan Activities
Activity
Description
Determine objectives
of test
This is the
what and why of this test. What are you trying to achieve and
why is it important to achieve it?
Determine testing
techniques to be used
What kind(s)
of testing will be done (reviews, walk-throughs, walking data
through code, computer execution)? This answers the 'how' of
step 1.
Select appropriate
test cases
Decide which
test cases should be included in this plan.
Maximize scheduling
of test runs
Arrange the
test runs for greatest efficiency. This step will vary greatly
according to the type of testing being done - in a system test.
It may be predetermined.
Identify needed
resources
What kinds
of resources do you need, how many and for how long? Customers,
developers, operations?
Establish start
and end dates
Based on the
current project schedule, the estimated testing effort and the
availability of required resources, when should these tests
start? When are they scheduled to be done?
Secure test
environment
Make sure everything
(people, machines, time) you need is available when you plan
to run the test.
Write up formal
test plan
Pull all information
into a document that can be put into the project documentation
and can be handed to someone else to finish the testing process
if necessary.
Review test
plan & obtain necessary approvals
Review the plan
with the appropriate people. You may need to repeat some of
the above steps to obtain the approvals.
Test Plan Components
1. Strategic Components
Component
Description
Test Plan Objective
Short description
of the test plan.
Business Risk
Description
of the risk to which the company will be exposed if the test
objective cannot be achieved.
Test Strategy
Definition
of the planned approach to achieving the objective of the test.
Scope
List of application
components to be or not to be tested.
Testing Techniques
Baseline testing,
Parallel testing, etc.
Resource Requirements
List of all
resources (hardware, software, people, training, testing tools)
including when and why (role) they are needed.
Required Completion
Date
The date by
which testing has to be complete to avoid endangering the planned
delivery date.
List of Related
Documents with Location
List of file
names containing information pertinent to the test plan.
Problem Reporting
Instructions
How discrepancies
will be recorded, reported and tracked.
Owner
Name of current
owner with effective date.
2. Scheduling Components
Component
Description
Assumptions
Critical assumptions
which, if not met, will influence the effort, duration or dates.
Planned Begin
of Testing
Date that the
test execution is expected to begin.
Planned End
of Testing
Estimated date
of test completion.
Estimated Effort
Amount of work
required to execute the tests.
Expected Duration
Amount of time
required to execute the tests.
Actual Begin
Date
The date test
execution is actually initiated.
Actual Completion
Date
The date the
objectives for this test plan are achieved.
Risk Management:
Prioritization by Severity of Error
This technique can be used to sequence test scenarios
based on the potential impact on the business environment.
Plan your
tests to start with possible category 4 errors, then category 3 errors,
etc.
Cat
Error
Examples
1.
System works, user
dissatisfied
Aesthetically offending, no functional impact Misleading
or redundant, small impact on performance Dehumanizing,
unnatural sequences, system must be tricked
2.
System does not work
correctly
Refuses legitimate transactions Loses track
of transactions, accountability is lost Transactions
incorrectly processed
3.
System is inherently
unreliable
Frequent and arbitrary occurrences of above mentioned errors Irrecoverable
corruption of data base occurs, serious thought to shutting system
down System fails,
shuts down itself
4.
System is out of
control
Corrupts other systems without failing itself; influence exceeds system
scope
Our eMentoring offer is a cost-effective alternative for small groups to learn these and
other business system analysis techniques at their own workplace or for follow-up after a
training seminar
Hathaway & Associates offers
training,
virtual and
in-house services to support a wide range of activities within the system development life cycle all targeted exclusively to the Business Analyst, Requirements Engineer and the Subject Matter Expert.
You can also visit our
bookstore for
the newest
in the business analysis field
Test Planning
Aesthetically offending, no functional impact
