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 user’s needs for the application. This is done over a
period of time, and going through various levels of requirements. This should
also portrays functionality 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 module’s importance and precisely the tester should
interpret 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.
Implicit Rules: Functionality that is implied based on what is expressed as a
specification/condition or requirement of a user. 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
SDLC MODELS:

Waterfall Model
This is the most common and classic of life cycle models, also
referred to as a linear-sequential life cycle model. It is very simple to
understand and use. In a waterfall model, each phase must be
completed in its entirety before the next phase can begin. At the end
of each phase, a review takes place to determine if the project is on
the right path and whether or not to continue or discard the project.
Unlike what I mentioned in the general model, phases do not overlap
in a waterfall model.

Advantages:
* Simple and easy to use.
* Easy to manage due to the rigidity of the model – each phase has
specific deliverables and a review
process.
* Phases are processed and completed one at a time.
* Works well for smaller projects where requirements are very well
understood

Disadvantages:
* Adjusting scope during the life cycle can kill a project
* No working software is produced until late during the life cycle.
 * High amounts of risk and uncertainty.
* Poor model for complex and object-oriented projects.
* Poor model for long and ongoing projects.
* Poor model where requirements are at a moderate to high risk of
changing.

Spiral Model

The spiral model is similar to the incremental model, with more

emphases placed on risk analysis. The spiral model has four phases:
Planning, Risk Analysis, Engineering and Evaluation. A software
project repeatedly passes through these phases in iterations (called
Spirals in this model). The baseline spiral, starting in the planning
phase, requirements is gathered and risk is assessed. Each
subsequent spiral builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk

analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis
phase.

Software is produced in the engineering phase, along with testing at

the end of the phase. The evaluation phase allows the customer to
evaluate the output of the project to date before the project continues
to the next spiral. In the spiral model, the angular component
represents progress, and the radius of the spiral represents cost.

Advantages:

* High amount of risk analysis

* Good for large and mission-critical projects.
* Software is produced early in the software life cycle

Disadvantages

* Can be a costly model to use.

* Risk analysis requires highly specific expertise.
* Project’s success is highly dependent on the risk analysis phase.
* Doesn’t work well for smaller projects.
Spiral Model
V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential
path of execution of processes. Each phase must be completed before
the next phase begins. Testing is emphasized in this model more so
than the waterfall model though. The testing procedures are
developed early in the life cycle before any coding is done, during each
of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model.
Before development is started, a system test plan is created. The test
plan focuses on meeting the functionality specified in the requirements
gathering.

The high-level design phase focuses on system architecture and

design. An integration test plan is created in this phase as well in
order to test the pieces of the software systems ability to work
together.

The low-level design phase is where the actual software components

are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place.
Once coding is complete, the path of execution continues up the right
side of the V where the test plans developed earlier are now put to
use.
Advantages:

* Simple and easy to use.

* Each phase has specific deliverables.
* Higher chance of success over the waterfall model due to the
development of test plans early on during the life cycle.
* Works well for small projects where requirements are easily
understood.

Disadvantages:

* Very rigid, like the waterfall model.

* Little flexibility and adjusting scope is difficult and expensive.
* Software is developed during the implementation phase, so no
early prototypes of the software are produced.
* Model doesn’t provide a clear path for problems found during
testing phases.

Prototyping Model

This is a cyclic version of the linear model. In this model, once

the requirement analysis is done and the design for a prototype is
made, the development process gets started. Once the prototype is
created, it is given to the customer for evaluation. The customer tests
the package and gives his/her feed back to the developer who refines
the product according to the customer's exact expectation. After a
finite number of iterations, the final software package is given to the
customer. In this methodology, the software is evolved as a result of
periodic shuttling of information between the customer and developer.
This is the most popular development model in the contemporary IT
industry.

Most of the successful software products have been developed

using this model - as it is very difficult (even for a whiz kid!) to
comprehend all the requirements of a customer in one shot. There are
many variations of this model skewed with respect to the project
management styles of the companies. New versions of a software
product evolve as a result of prototyping.
Advantages:

* May provide the proof of concept necessary to attract funding

* Early visibility of the prototype gives users an idea of what the
final system looks like
* Encourages active participation among users and producer
* Enables a higher output for user
* Cost effective (Development costs reduced)
* Increases system development speed
* Assists to identify any problems with the efficacy of earlier design,
requirements analysis and coding activities
* Helps to refine the potential risks associated with the delivery of
the system being developed

Disadvantages:

* User’s expectation on prototype may be above its performance

* Possibility of causing systems to be left unfinished
* Possibility of implementing systems before they are ready.
* Producer might produce a system inadequate for overall
organization needs
* Producer might get too attached to it (might cause legal
involvement)
* Often lack flexibility
* Not suitable for large applications
* Project management difficulties
Rapid Application Development (RAD) Model:

The RAD models a linear sequential software development

process that emphasizes an extremely short development cycle. The
RAD model is a "high speed" adaptation of the linear sequential model
in which rapid development is achieved by using a component-based
construction approach. Used primarily for information systems
applications, the RAD approach encompasses the following phases:

1. Business modeling
The information flow among business functions is modeled in a way
that answers the following questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?

2. Data modeling
The information flow defined as part of the business modeling
phase is refined into a set of data objects that are needed to support
the business. The characteristic (called attributes) of each object is
identified and the relationships between these objects are defined.
3. Process modeling
The data objects defined in the data-modeling phase are
transformed to achieve the information flow necessary to implement a
business function. Processing the descriptions are created for adding,
modifying, deleting, or retrieving a data object.

4. Application generation
The RAD model assumes the use of the RAD tools like VB,
VC++ and Delphi etc... Rather than creating software using
conventional third generation programming languages. The RAD model
works to reuse existing program components (when possible) or create
reusable components (when necessary). In all cases, automated tools
are used to facilitate construction of the software.
5. Testing and turnover
Since the RAD process emphasizes reuse, many of the program
components have already been tested. This minimizes the testing and
development time.

MADHU BABU…………………..