Test Planning

And the Test Plan

A. Test Planning Approach

• Test Plan Guidelines– Goals– Ingredients– Sequence of events– Meet or exceed expectations– Introduce & explain– Prove and document system readiness

Details of QC

Test Planning Approach

• Is the test plan a tool or product?

• Establishing Test Coverage– Linking it to the test requirements

Details of QC

Agenda1. The Hierarchy of a Test Requirement

2. Generating a Test Requirement Hierarchy

3. A quick look at Test Coverage Measures

4. Anatomy of a Test Plan

Test Requirements

• Why identify them?

• What exactly is a Test Requirement?

• Where does a Test Requirement come from?

Drilling down

BusinessR equirem ent

TestRequirement

TestScenarios/Cases

TestProcedure/Script

(the infamous) ATM Example

Business Requirements:

- “ATM must do withdrawals”

- “Withdrawals are between $20-$300”

- “Withdrawals are in $20 multiples”

Group Exercise!

1. What tests would you create?

2. What will you validate?

3. Are there any implied requirements that may not be written out?

Test Scenarios/Cases for - “Validate that a withdrawal of a multiple of $20,

between $20-$300 can be done”

Case # P/F $ entered ExpectedResults

ActualResults

WD01 Pass 20 $20 withdrawnWD02 Pass 40 $40 withdrawnWD03 Pass 60 $60 withdrawnWD04 Pass 80 $80 withdrawn

WD05 Pass 100 $100 withdrawn: : : :

WD13 Pass 260 $260 withdrawnWD14 Pass 280 $280 withdrawnWD15 Pass 300 $300 withdrawn

Test Procedure & Script for previous example

Step 1: Insert Card

Step 2: Enter PIN

Step 3: Select Withdraw option

Step 4: Enter dollar amount

Step 5: Validate amount received

Do until EOF ‘until end of data file

Input data record

Senddata CARDINFO to “Cardfield”

Senddata “Enter”

Senddata PIN to “PINFfield”

Senddata “Enter”

Senddata “W” to “SelectionField”

Senddata AMOUNT to “DollarField”

Senddata “Enter”

If ErrorMsg > 0 then print ErrorMsg

Print “DollarAMTgiven”

Loop

Procedure: Script: (in pseudo-code )

2. Generating a Test Requirement Hierarchy

• Remember that different applications organize in different ways

• Maintain a level of balance between too much & too little

• Generally, organize your testing by Type of Test

Test Requirement DecompositionBusiness P rocess/

Function

Tasks with in theFunction

D ata Entry Typesfor transactions

Transactions toperform a task

F ie ld Validation

The "what" that the software is in tended todo, like "Rent a Car to a custom er"

The tasks involved: 1) query car rates,2) check custom er policy coverages, ....

The database transactions necessaryto perform the task.

The edits on the data included w ith inthe d ifferent types

The types of data entry thetransaction can process: Add,

Change, Delete, Inquire

3. A quick look at Test Coverage Measures

• Test Requirements are the “what” of testing

• TR’s give us the point of measurement for test coverage

• Each TR should be tracked for Verification () and Validation (%)

4. Anatomy of a Test Plan

• Review the parts of a test plan

• Review the process of the test plan creation process

• Develop your own template

• Who, What, When, Where, Why, & How

3 cardinal rules for test plans

• A Test Plan is a contract between the tester and the development team

• A Test Plan should always be written for another tester to implement

• A Test Plan is a synthesis of the standards & guidelines of your QC process for the particular project

Test Plan Scope Disclaimer

• The size of a test plan & the effort of creating it, is directly proportionate to the size of the project.

• A good test plan, regardless of size, always addresses all the following themes

• A successful QC person addresses the entire QC process within the scope of the test plan

The Test Plan Process

1. Identify the scope and Test Requirements

2. Identify the Test Priority

3. Develop a testing strategy

4. Identify resources

5. Create the schedule

6. Compile the test plan

7. Test plan is approved and testing is executed

8. Results are documented

Some Test Plan Parts

1. Project Definition & Background

2. Target Dates

3. Test Requirements Hierarchy

4. Strategy or Approach for each of the areas of QC

5. Risks & Dependencies

6. Unresolved / Open Issues

7. Resources

8. Document Tracking

9. Results / Summary

Review Sample Test Plans

1. What is Good?

2. What is Bad?

3. What is Missing?

4. General observations?