Software Test Plan

1
Software Test Plan

• Why do you need a test plan?
• Provides a road map
• Provides a feasibility check of
• Resources/Cost
• Schedule
• Goal
• What is a test plan?
• A document that outlines
• What is the goal of this testing effort (exit
  criteria)
• What are the items to be tested
• High level list
• Detailed features
• What test process will be used
• For different deliverables and different features
• What record keeping and measurements will be
  performed
• What resources are needed
• What is the schedule
• What are the risks and contingencies

2
Goal(s) of Your Testing

• Goals may be different for each test.
• They often need to match the product goal or the
  project goal
• Generic Meets customer requirements or
  satisfaction is a bit too broad.
• A Level Deeper Examples are
• Ensure that all the (requirements) features exist
  in the system
• Ensure that the developed components and the
  purchased components integrate as specified
• Ensure that performance targets (response time,
  resource capacity, transaction rate, etc) are
  met.
• Ensure the system is robust (stress the system)
• Ensure that the user interface is clear,
  novel, or catchy, etc.
• Ensure that the required functionality and
  features are high quality.
• Ensure that industry standards are met.
• Ensure that internationalism works (laws and
  looks)
• Ensure that the software is migratable

3
Test Items

• Testing the deliverables (Depends on the goal)
• Requirements specification
• Design specification
• Executable code
• User guides
• Initialization data
• Testing the individual function/features (Depends
  on the goal)
• Logical application functions (list all of them
  usually from requirement spec. - - - from the
  users perspective)
• At the detail level for small applications (list
  all the modules from design spec. or build list
  - - - from development perspective)
• User interfaces (list all the screens usually
  from Req. and Design spec.)
• Navigation (if usability is a goal)

4
Not included in the Test

• List of items not included in this test
• Possible Reasons
• Low risk items
• Future release item that is finished coding phase
• Not a high priority item (from req. spec.)

5
Test Process

• What testing methodology will be applied
• Non executable
• formal inspection, informal reviews, (unit test
  user guide examples)
• Executable
• unit test, functional test, system test,
  regression test, etc.
• Blackbox testing
• Data flow testing
• Boundary analysis
• Stress testing and performance testing
• Installation test
• Whitebox testing
• Path testing
• Object testing (inheritance, polymorphism, etc.)
• What test-fix methodology will be applied
• What promotion and locking mechanism will be
  used.
• What data will be gathered and what metrics will
  be used to gauge testing.
• of Problems found by severity, by area, by
  source, by time
• of problems fixed, returned with no resolution,
  in abeyance

6
Test Resources

• Based on the amount of testing items and testing
  process defined so far, estimate the people
  resources needed
• The skills of the people
• Additional training needs
• of people
• The non-people resources needed
• Tools
• Configuration management
• Automated test tool
• Test script writing tool
• Hardware, network, database
• Environment (access to developers, support,
  systems, etc.)

7
Test Schedule

• Based on
• Amount of test items
• Test process and methodology
• Test resources
• A schedule containing the following information
  should be stated
• Task
• Assigned person
• Time duration

8
Risks and Contingencies

• Examples of Risks
• Changes to original requirements or design
• Lack of available and qualified personnel
• Lack of (or late) delivery from the development
  organization
• Requirements
• Design
• Code
• Late delivery of tools and other resources
• State the contingencies
• Move schedule
• Do less testing
• Change the goals and exit criteria