Test Strategy

A Test Strategy document is a high level document and normally developed by project
manager. This document defines “Testing Approach” to achieve testing objectives. The
Test Strategy is normally derived from the Business Requirement Specification
document.

The Test Stategy document is a static document meaning that it is not updated too often.
It sets the standards for testing processes and activities and other documents such as the
Test Plan draws its contents from those standards set in the Test Strategy Document.

Some companies include the “Test Approach” or “Strategy” inside the Test Plan, which is
fine and it is usually the case for small projects. However, for larger projects, there is one
Test Strategy document and different number of Test Plans for each phase or level of
testing.

Components of the Test Strategy document

 Scope and Objectives

 Business issues
 Roles and responsibilities
 Communication and status reporting
 Test deliverability
 Industry standards to follow
 Test automation and tools
 Testing measurements and metrices
 Risks and mitigation
 Defect reporting and tracking
 Change and configuration management
 Training plan

Test Plan
The Test Plan document on the other hand, is derived from the Product Description,
Software Requirement Specification SRS, or Use Case Documents.
The Test Plan document is usually prepared by the Test Lead or Test Manager and the
focus of the document is to describe what to test, how to test, when to test and who will
do what test.

It is not uncommon to have one Master Test Plan which is a common document for the
test phases and each test phase have their own Test Plan documents.

There is much debate, as to whether the Test Plan document should also be a static
document like the Test Strategy document mentioned above or should it be updated every
often to reflect changes according to the direction of the project and activities.
My own personal view is that when a testing phase starts and the Test Manager is
“controlling” the activities, the test plan should be updated to reflect any deviation from
the original plan. After all, Planning and Control are continuous activities in the formal
test process.

 Test Plan id
 Introduction
 Test items
 Features to be tested
 Features not to be tested
 Test techniques
 Testing tasks
 Suspension criteria
 Features pass or fail criteria
 Test environment (Entry criteria, Exit criteria)
 Test delivarables
 Staff and training needs
 Responsibilities
 Schedule

hi balaji,

TEST STRATEGY is a company level document developed by quality analyst

people.This document defines the testing approach to be followed by the testing team. it
consists of

1) Scope and objective: The purpose of testing in an organization

2) Business issues: Budget control for testing
3) Testing approach: That is the TRM ( Test responsibility Matrix)
4) Test Delivarables: Names of the testing documents to be prepared by the Testing Team.
5) Roles and Responsibilities: Names of jobs in the testing team and their responsibilities
6)Communication and status reporting: Required negotiation between two jobs in a team
7) Test automation and Tools: Availability of testing tools and purpose of automation
8) Defect reporting and Tracking: required negotiation between testing and development
teams
9) Risks and Migitations: Expected failures during testing and solutions to overcome
10) Change and Configuration management: How to handle sudden changes in customer
requirements.
11) Training plan :

on the other hand TEST PLAN is a document which defines basically..

1) what to test?
2) how to test ?
3) when to test ?
4) who to test?
Documentation specifying the scope, approach, resources, and schedule of intended
testing activities. It identifies test items, the features to be tested, the testing tasks,
responsibilities, required, resources, and any risks requiring contingency planning
Test lead prepares this document. It is normally defined in IEEE829 format which is as
follows
1 ) Test plan ID : Unique number or name
2) Introduction : About project
3) Test Items: Names of all modules in the project.
4) Features to be tested :
5)Features not to be tested:
6) Tessting approach: finalized TRM, selected testing techniques
7) Entry Criteria : When testing can be started
8) Exit Criteria : when testing can be stopped
9)Fail or Pass criteria:
10) Test Environment : The environment where the test is to be carried out.
11) Test Delivarables:
12) Staff and training
13) Roles and Responsibilities
14 ) Project starting and End dates
15) Risks and migitations.

A test scenario is almost like a story like example "a user enters into the
application from login window by entering valid user name and password.After
entering he will click on module Payslip and clicks on latest payslip feature to
view his latest payslip".Any test scenario will contain a specific goal.
A test case can be derived from a scenario .For the above scenario we can write
a test case like :
Test Case # 1:
S.No Steps Expected
1 Open the login window Login window is open
2 Enter valid UN & Pwd Application should be open
3 Click on Payslip Features in payslip should be displayed
4 Click on latest payslip feature It should open latest payslip window
Above is a positive test case and a negative test case can also be prepared.A test
case is prepared and executed with a goal to find the hidden defects with
different possibilities.
Answer Question
2 Users have rated as useful.
Login to rate this answer.
ravi
Answered On : Jun 30th, 2006
Test Scenario: From Use Case & Functionality Requirement of the Application.
Test Case: From Test Scenario (Use Case & Funtionality Requirement) of App.

I want to give simple example for Test scenario and Test cases

For Example:If i want to validate the login page

Test Scenario will be: User receives an error message when he enters invalid
parameters in the login page.

Test Cases 1: User receives an error message when he enters valid userid and

invalid password.
Test Cases 2: User receives an error message when he enters invalid userid
and
valid password
Test Cases 3: User receives an error message when he enters invalid userid
and
invalid password

Based on the Test Scenario ,Test engineer are writing test cases.

Verification is Static while Validation is Dynamic. This means in Verification the

s/w is inspected by looking into the code going line by line or function by function.
In Validation, code is executed and s/w is run to find defects. Since in verification
code is reviewed, location of the defect can be found which is not possible in
validation.

Testing - Difference between Verification and Validation - March 02, 2010 at

5:00 AM by Vidya Sagar

Difference between Verification and Validation

Verification - is to determine the right thing, which involves the testing the
implementation of right process. Ex: Are we building the product right?

Validation - is to perform the things in right direction, like checking the developed
software adheres the requirements of the client. Ex: right product was built
Testing - Difference between Verification and Validation - August 11, 2008
at 13:10 pm by Shuchi Gauri

Difference between Verification and Validation

Verification: To check if we are doing the right thing.

Validation: To check whether we have developed the software as per the client’s
requirements or not.

Verification is done through out the life cycle of the

project/product where as validation comes in the testing
phase of the application.

Verification -> Are we building product right?

Validation -> Are we building right product?

As mentioned above, Priority and Severity are two, very distinct properties of a
Bug/Task. The example of a backwards logo on a splash screen is a good one - Minimal
Severity (zero effect on software functionality), but High Priority (extremely obvious and
affects every user).

Severity: Impact of the defect 2 Sushma

on the Application. Assigned
by Testers.

Priority:Impact of the defect

w.r.t users.
: How fast we have to
solve the defect.

Is This Answer 14 Yes

Correct ? 5 No

Re: Difference between Severity

& Priority?
Answer Severity is
#2 seriousness of
the bug
where
Priority is How
fast the bug
should be
rectified?
 Severity - impact of the bug 0 Sara
on the functionally
priority - order of important
of the bug

Is This Answer
Correct ? 4 Yes 5 No

Re: Difference between

Severity & Priority?
Answer I can
#6 differenciate with
example
suppose we
identify two bugs
1. The client logo
is not appearing
on the web site
but the
site is working
fine... in this
case the severity
is low but
the priority is
high because from
company's
reputation it is
most imp to
resolve. After all
the reputation
wins more
clients and
projects and hence
increases revinue

show stopper:4,Major defect:3,Minor defect:2,Cosmetic:1

setting values for these four categories can be again defined by the organisation
based on their views.
showstopper: this have a higher severity as u cannot proceed further testing
with the application testing.
Major: If there are any main defect based on the functionality .
Minor: If there is any error in the functionality of one object under one
functionality
Cosmetic: any error based on the look and feel of the system,or improper
location of the object(something based on the design of the web page)
Priority: this will be set by the team lead or the project lead. Low high medium
based on the severity and the time constraint that the module has the priority
will be set
Answer Question
4 Users have rated as useful.

Login to rate this answer.

srini.g
Answered On : Oct 5th, 2005
Seviority means how server is the functionality effected by the bug(or
mismatch).Priority means how quickly the bug should be fixed.

Software Development Phases

Most of the processes outlined above encompass most or all of the following activities or
phases:

 Concept Exploration: At this phase, concepts are explored, other

alternatives (other than developing the system) are considered.
 Requirement: The software functionality is determined from a user's point
of view (user's requirements) and a system's point of view (system's
requirements).
 Specifications: The requirements are turned into rigorous specifications.
 Design: The requirements are transformed into a system design. The
requirements are partitioned into groups and assigned to units and/or
subsystems, then the relationships (interfaces) between those units and/or
subsystems are defined.
 Unit Build and Test: The design is transformed into code for every unit.
Every unit is then tested.
 Integration and Test: Units are brought together, preferably in a
predetermined order, to form a complete system. During this process, the
units are tested to make sure all the connections work as expected.
 System and Users' Acceptance Testing: The entire system is tested
from a functional point of view to make sure all the functions (from the
requirements) are implemented correctly and that the system behaves the
way it is supposed to all circumstances.
  Operation, Support, and Maintenance: The system is installed in its
operational environment and, as it is being used, support is provided to
the users. As the system is used, defects might be discovered and/or
more functionality might be needed. Maintenance is defined as correcting
those defects and/or adding functionality.

simplicity and certain similarities in their accomplishment, some of the phases

that require similar techniques are combined here. These are:

 Definition Phase: This phase includes the Requirements and

Specifications phases.
 Design Phase: High- (software architecture) and low- (unit and/or object)
level design.
 Code: The Build Code (construction) phase
 Unit and Integration Tests: These are combined because they are both
concerned with the structure (white-box) testing and, in most instances,
are performed by the programmers.
 System and User's Acceptance Testing: These tests are concerned
more with the functional (black-box) testing and performed by testers
(which may or may not be in the same organization as the programmers).