Test plan, test case and test data preparation

Introduction

Effective testing depends on a well-planned test specification and steps to execute tests with necessary test data. A product’s quality depends upon the quality of the test cases it has been put through. Hence the objective of test planning for software should aim to detect more errors.

Test Planning

Test Plan preparation or test planning is the foremost activity in the preparation to test a product. Test plans can be prepared for any of the identified testing strategies. Test plan enables the identification and definition of test cases objectives across “functional areas” or “test criteria” applicable for the chosen test strategy. These criteria are the major focus areas of testing for a given test strategy.

Test Criteria

Test criteria / functional areas for a typical Client/Server business application system like ours can have the following test criteria:

Field Level Validations: The aim of this functional area of testing is to uncover field property related errors. The test cases associated to this functional area target null / not-null checks, data type validations, data entry masks etc,.

Field Level Dependencies : Very often, it is found that values entered for a particular field are supposed to be validated with respect to the value contained in another field. The ‘field level dependency’ test cases should aim to uncover defects relating to the non-validation of dependent screen field values with respect to the independent fields. E.g. ‘To’ date in a range of dates depends upon the ‘From’ date.

Functionality validations : Application functionality is implemented in applications through a variety of interface controls. The “functional validation” test cases aim to test each interface control provided by the application and verify intended implementation. E.g., the graying of status icons, activeness of menu items etc,.

Referential Integrity Checks : Most business applications involve master data that are referenced by the application’s transactions. The application cannot have transactions without the corresponding master data. ‘Referential integrity’ test cases aim to uncover such errors in the application.

Referential Integrity checks can be planned for unit and multiple levels of integration testing.

Business Rule validations : Business applications are built on a business model of that application. Business rules are sequencing rules of the application. E.g.,. approved Purchase requisitions precede the preparation of Purchase orders. “Business rule validation” test cases aim to uncover these functional deficiencies of the application with respect to the requirements specification.

Boundary value validations : Applications allow definition of a range of parameters and operate within their boundary. “Boundary value validation” test cases aim to check the functionality of the application with respect to the values of the parameters in the upper and lower boundary. E.g..

Test Case Nomenclature

Test cases are identified during the test planning stage for every test criteria / functional area identified. This standardization is needed for :

· Effective association of the test case to features

· Effective documentation of defects detailing test cases that failed

· Effective regression testing

Presented below is a nomenclature standard for the test cases identified :

AAAVV / MM / FFF / nnn

where AAA refers to the application identifier E.g.,. IMS

VV refers to the version number of the application

MM refers to the Module id E.g., GI - Goods Inward

FFF refers to the feature id E.g.,. 180 - GI main screen

nnn refers to the document number.

Test Completion Criteria

Test completion criteria should mention the exit criteria for a test plan. The statement of “when to stop testing” should come out clearly. The objective of the

testing exercise must be defined as the test completion criteria. A sample test completion criteria could be stated for a unit test plan of a transaction screen as :“Software unit can be declared as unit tested if and only if all test cases defined are executed to meet the expected outcomes”.

Test Cases

Test Case is a document that specifies the test inputs, execution conditions, and predicted results for an item to be tested with respect to the testing criteria and its objective.

Test Sequence Preparation

Test sequences are execution steps in meeting the test case objectives. Test sequences are prepared in a manner that each individual steps are traceable during execution. Expected outcomes may not be available for every test sequence step. However, the structuring of test sequences should be such that expected outcomes are definable.

Test sequences should cover both valid and invalid outcomes.

Test Data

Test sequences in many test criteria like referential integrity validation, business rule checks and functionality validations require sample data that are used to check valid and invalid outcomes. These test data are listed along with the corresponding sequences or loaded through script files.