Testing Procedure

Aditi Technologies Pvt. Ltd. Testing procedure

Revision History
SL Versio Date Nature of change Affecte Author Reviewer Approved
N n No d By
o. pages
1 1.0 24/7/20 2 Kaliraj T S.A.Warri S.A.Warrier
01 er
2 2.0 12/1/20 Addition of 8,13 Naresh S.A.Warri S.A.Warrier
01 Copyright Kamath er
information and
change in footer,
Change in test
plan template.
3 3.0 31/1/20 Addition of unit 13 Kaliraj T CSA Rao CSA Rao
02 test plan (Refer
CRF036)
4 4.0 22/2/20 Change in Test 13 Kaliraj T CSA Rao CSA Rao
02 Case template
(Refer CRF037)
5 5.0 14/3/20 Change in test 13 Kaliraj CSA Rao CSA Rao
02 plan template.
Removal of unit
test plan
template(Refer
CRF038)
6 6.0 16/12/2 Change in the ALL Sunil Kumar Srikanth Srikanth D.S
003 procedure D.S,
structure, Indukuma
Introduction of r
test readiness
checklist and
testing checklist,
change in test plan
structure, removal
of copyright page.
(Refer CRF081)
7 7.0 17/3/20 Addition of 8 Naresh Srikanth Srikanth D.S
04 Severity definition Kamath D.S
(Refer to CRF091)

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 2 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

Table of Contents

1. SCOPE......................................................................................................5
2. RESPONSIBILITY........................................................................................5
3. PROCEDURE DESCRIPTION...........................................................................5
3.1. Introduction..............................................................................................................5
3.2. Testing Activities....................................................................................................5
3.3. Entry and Exit Criteria for Testing phases /activities..........................................10
4. PROCESS FLOW DIAGRAM...........................................................................11
5. REFERENCE DOCUMENTS...........................................................................11
5.1. Templates.................................................................................................................11
5.1.1. Test Plan......................................................................................................................... 11
5.1.2. Acceptance Criteria........................................................................................................ 12
5.1.3. Test case Design............................................................................................................. 12
5.1.4. Integration Testing Document......................................................................................12
5.1.5. System Testing Document............................................................................................12
5.2. Procedures...............................................................................................................12
5.2.1. Test Effort Estimation.................................................................................................... 12
5.2.2. Build management......................................................................................................... 12
5.2.3. Release note.................................................................................................................... 12
5.2.4. Test case review Checklist.............................................................................................. 13
5.3. Guidelines................................................................................................................13
5.3.1. Types of testing to be performed on different types of projects...................................13
5.3.2. Unit/integration/system Test plan guidelines.............................................................13
5.3.3. Defect Life Cycle............................................................................................................. 13
5.3.4. Entry and Exit Criteria document.................................................................................13
5.3.5. Project Kick Off.............................................................................................................. 13
APPENDIX A.................................................................................................14

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 3 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

1. Purpose
The Purpose of the document is to streamline testing activities in the
organisation.

2. Scope
This document deals with the entire testing activity that is done in Aditi. Right
from Acceptance criteria preparation, Test planning, Test execution to release.

3. Responsibility

Sl Activity Responsibility
No
1 Requirement review and Test Engineer/ Test
Acceptance Criteria Lead/Manager in consultation
with Dev Team
2 Test Plan Test Lead/Manager
3 Test Cases Test Engineer
5 Tracking of defects Test Lead/Manager
6 Test Reports Test Lead/Manager

4. Procedure description
4.1. Introduction
Software testing is an integral part of software development
process. Testing is a technique used to determine the solution that solves
the problem. Testing encompasses the following three concepts.

 Demonstration of the validity of software at each stage in the system

development life cycle.
 Determination of the validity of the final system with respect to user
needs and requirements
 Examination of the behavior of a system by executing the system on
sample test data

Testing has a life cycle of its own and there is useful and constructive
testing to be done throughout the entire life cycle of development. This
means that testing process begins with the Requirements phase and from
there parallels the entire development process. In other words, for each
phase of the development process there is an important testing activity.
This necessitates the need to migrate from an immature, ad-hoc way of
working to having a full-fledged Testing Process.

4.2. Testing Activities

The testing procedure consists of following activities.

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 4 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

4.2.1. Acceptance criteria preparation and review

During requirements review stage, the testing team arrives at

“acceptance criteria”. This is generally provided by the client and reviewed
and approved by the Project Team (Development and Testing). In the
event of Client not providing any such criteria, the Testing team, in
consultation with Dev Team suggests acceptance criteria. This undergoes
review by Project team before getting accepted by the customer.

4.2.2. Requirements Analysis – Testing perspective

Analysis and study of requirements by the test team to achieve

 Further refine Test plan.
 Test Estimates.

4.2.3. Preparation of Test plan

The test plan is the set of ideas that guide or represent the
intended test process. Test plan is a document that covers the entire
Testing process from planning and execution point of view. The document
aims at identifying the software product risks, Types and levels of Testing
required, Logistics, Test bed details etc. The Test plan needs to be shared
with all the stakeholders for the project – Development Team, PM and
client and opinions, comments are sought in order to make Testing more
effective and efficient. Please refer to section 6.1 for test plan template
4.2.4. Test Setup
If the required software and Hardware for testing, identified in the
test plan are not available, they are procured through ISG. The task is
owned by test lead. A Separate Defect database is created for each
project. If the test plan identifies some training on tools and/or
Technologies for Testing, the test team members undergo the training.
Before the start of Test execution activity by testing team, Test
machines are set as per Test plan.

4.2.5. Test case design and review

The test cases are developed in the implementation phase of the
project. Functional specification document, Test Plan and design
document are taken as input for the test case generation. The goal in the
generation of test cases is to exercise the component’s logic and to setup
testing scenarios that will expose errors, omissions and unexpected
results. Refer Test case Design Template.

The test cases written by the testers go thru a round of review by peers/
Test lead/ Developer. A sub set of test cases per module or unit or
identified as “BVTs”. These cases are good candidates for automation and
run for every build.

During this process, Test lead/Manager revisits the test estimates and
escalates any major deviations.

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 5 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

4.2.6. Test Data generation

From the test case document the requirement for test data is
analyzed and the data is generated.

4.2.7. Build Management

Testing team takes the responsibility of making “builds” and

releasing for Testing. One member of the Testing team is designated as
Build Engineer and carries out all build related activities.

4.2.8. Unit testing

As per the traditional “V” diagram of STLC – software Testing life
cycle, testing begins with Unit testing. Unit testing makes heavy use of
White Box testing techniques, exercising specific paths in a unit control
structure to ensure complete coverage and maximum error detection.
Unit testing is focused on verification effort on the smallest unit of
software design. The units are identified at the detailed design phase of
the software development life cycle, and the unit testing can be conducted
parallel for multiple units. Units that cannot be tested in isolation may
require the creation of small test programs known as test harness.

4.2.9. BVT Set

This is set of basic functionality test cases taken out of functional test
cases of the application. The build is taken for further testing only if all
the test cases in BVT are successfully executed otherwise the build is
rejected.

4.2.10. Module Testing

This is first phase from where the testing Team starts its execution. The
drops released for Testing are taken and tested as per the feature-
list specified in the release notes .

4.2.11. Integration testing

Integration Testing mainly aims at verifying the interactions
between program units and is performed according to Integration Test
case Document. The focus during this phase of testing would be to
“identify the unit/module boundaries” and check that interfaces between
modules/units work as specified.
Black-box test case design techniques are suitable during
integration testing, although limited amount of white box testing may be
used to ensure coverage of major control paths.

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 6 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

4.2.12. System testing

After the software has been integrated (constructed), sets of high order
tests shall be conducted.
The purpose of system testing is to fully exercise the computer-based
system. The aim is to verify that all system elements and validate
conformance against SRS. The main focus of this phase of testing is to
run the system thru typical user scenarios, End to End testing and set of
Non Functional Testing as specified by Test plan.

Before the start of system testing the testing team needs to verify the
following

1. Test Readiness checklist

The tester/test lead verified against this checklist before actually
starting off the testing activity. The intent of this form is to
provide a Roadmap/guideline for the test lead to check the
readiness/availability of test environment. Refer Test Readiness
Checklist

2. Testing Checklist
This form is used as a working tool for the testers for testing
activities. The intent of this form is to provide a roadmap/guideline
for the tester to conduct the testing activity. Refer Testing
Checklist

4.2.13. Regression Testing

This activity happens right from module Testing till system Testing.
In the minimal form this activity is nothing but Running BVTs. Depending
upon the complexity and size of the project, BVTs can be extended to
form bigger set of test cases to form “regression test case” set.

Another significant portion of Regression testing is regressing defects. For

every build subsequent to first build, there will be defect fixes, so test
team needs verify the fixes for these fixes and carry out additional
testing.

The test team will get the information from the release notes of every
builds about the defects fixed in every build.
4.2.14. Test execution tracking
The Test lead will on day by day basis or build-wise track the
progress of the testing.
4.2.15. Defect recording and tracking
The major activity during Testing apart from executing test cases is
recording defect clearly and unambiguously so that get fixed soon.
Defect recording is responsibility of individual tester who finds the

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 7 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

defect. The defects are recorded in Defect tracking database identified

for the project.
The defects are categorized based on severity and priority. The
severity definition is as below.

Severity Definition
S1 The defect prevents the system from meeting its specification
and there is no workaround
S2 The defect prevents the system from meeting its specification
but there is a workaround.
S3 The defect does not prevent the system from meeting its
specification or the defect does not prevent the system from
functioning in any way and this refers to visual defects and
defects in nice to have features.

The status of the bug is active, when encountered by the testing

team. The developers fix the bugs logged, and change the status of the
bug to resolve.
A new release/build of the product is released for testing. The
test team verifies the bugs and the status of the bugs are modified to
reopened or closed. The process of fixing and closing the bug continues
until the bug is fixed completely and does not surface again.

4.3. Entry and Exit Criteria for Testing phases /activities

Refer Entry and Exit Criteria document.

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 8 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

5. Process flow diagram

6. Reference documents
6.1. Test Plan

"Test plan.doc"

6.2. Acceptance Criteria

"acceptance Criteria
Template.xls"

6.3. Test case Design

"Test acse design

template.xls"

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 9 of 10

Aditi Technologies Pvt. Ltd. Testing procedure

6.4. Test Readiness checklist

"Test readiness
checklist.doc"

6.5. Testing Checklist

"Testing
checklist.doc"

6.6. Release to testing template

Defect
Verification Document

6.7. Entry and Exit Criteria document

Entry_Exit_Criteria.x
ls

ADITI/QMS/QPTST / 7.0 © Copyright Aditi Page 10 of 10