Test Preparation Process
Written on 10:23 PM by MURALI KRISHNA
Test Preparation Process
Baseline Documents
Construction of an application and testing are done using certain documents. These documents are written in sequence, each of it derived from the previous document.
Business Requirement
This document describes users needs for the application. This is done over a period of time, and going through various levels of requirements. This should also portrays functionalities that are technically feasible within the stipulated times frames for delivery of the application.
As this contains user perspective requirements. User Acceptance Test is based on this document.
How to read a Business Requirement?
In case of the Integrated Test Process, this document is used to understand the user requirements and find the gaps between the User Requirement and Functional Specification.
User Acceptance Test team should break the business requirement document into modules depending on how the user will use the application. While reading the document, test team should put themselves as end users of the application. This document would serve as a base for UAT test preparation.
Functional Specification
This document describes the functional needs, design of the flow and user maintained parameters. These are primarily derived from Business Requirement document, which specifies the client's business needs.
The proposed application should adhere to the specifications specified in this document. This is used henceforth to develop further documents for software construction and validation and verification of the software.
In order to achieve synchronization between the software construction and testing process. Functional Specification (FS) serves as the Base document.
How to read a Functional Specification?
The testing process begins by first understanding the functional specifications. The FS is normally divided into modules. The tester should understand the entire functionality that is proposed in the document by reading it thoroughly.
It is natural for a tester at this point to get confused on the total flow and functionality. In order to overcome these, it is advisable for the tester to read the document multiple times, seeking clarifications then and there until clarity is achieved.
Testers are then given a module or multiple modules for validation and verification. These modules then become the tester's responsibility.
The Tester should then begin to acquire an in-depth knowledge of their respective modules. In the process, these modules should be split into segments like field level validations, module rules, business rules etc. In order to do the same modules precisely the tester should interpret importance and its role within the application.
A high level understanding of the data requirements for respective modules is also expected from the tester at this point.
Interaction with test lead at this juncture is crucial to draw a testing approach, like an end-to-end test coverage or individual test. (Explained later in the document)
Tester's Reading Perspective
Functional specification is sometimes written assuming some level of knowledge of the Testers and constructors. We can categorize the explanations by
Explicit Rules: Functionality expressed as conditions clearly in writing, in the document.
Example
Date of a particular field should be system date
Implicit Rules: Functionality that is implied based on what is expressed as a specification/condition or requirement of a user.
Example
FS would mention the following for a deposit creation
Start Date Field: Should be = or > than the system date
Maturity Date Field: Should be = or > than the system date
Under this condition, the implied specification derived is that, Start date should not be equal to the maturity date
The tester must also bear in mind, the test type i.e. Integrated System Testing (IST) or User Acceptance Testing (UAT). Based on this, he should orient his testing approach.
Design Specification
This document is prepared based on the functional specification. It contains the system architecture, table structures and program specifications. This is ideally prepared and used by the construction team. The Test Team should also have a detailed understanding of the design specification in order to understand the system architecture.
System specification This document is a combination of functional specification and design specification. This is used in case of small applications or an enhancement to an application. Under such situations it may not be advisable make two documents.
Prototype
This is look and feel representation of the application that is proposed. This basically shows the placement of the fields, modules and generic flow of the application. The main objective of the prototype is to demonstrate the understanding of the application to the users and obtain their buy-in before actual design and construction begins.
The development team also uses the prototype as a guide to build the application. This is usually done using HTML or MS PowerPoint with user interaction facility.
Scenarios in Prototype
The flow and positioning of the fields and modules are projected using several possible business scenarios derived from the application functionality.
Testers should not expect all possible scenarios to be covered in the prototype.
Flow of Prototype
The flow and positioning are derived from initial documentation off the project. A project is normally dynamic during initial stages, and hence tester should bear in mind the changes to the specification, if any, while using the prototype to develop test conditions.
It is a value addition to the project when tester can identify mismatches between the specifications and prototype, as the application can be rectified in the initial stages itself.
