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

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

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)

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.)

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 –# of problems resolved by severity, turn around time, by area, etc. How to gauge if goals are met –Metrics for validating the goal –Decision process for release

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.)

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

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