NRTRDE Processing System
Software Testing Policy
Version 1.0
Doc. No.:
NRTRDE Processing System
Version:
1.0
Revision History
Date
2010-01-08
Version
1.0
Description
First version
Author
Muhammad Siddique
Page 2
NRTRDE Processing System
Version:
1.0
Table of Contents
1. Introduction ........................................................................................................................................................ 4
1.1
1.2
1.3
1.4
1.5
1.6
Purpose of this document ................................................................................................................................. 4
Document organization .................................................................................................................................... 4
Intended Audience ............................................................................................................................................ 4
Scope ................................................................................................................................................................ 4
Definitions and acronyms ................................................................................................................................ 4
References ........................................................................................................................................................ 4
2. Test policy statement/goals ................................................................................................................................. 5
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
Delivering high quality software product ........................................................................................................ 5
Testing approach.............................................................................................................................................. 5
Testing: what,when,how ................................................................................................................................... 5
Communication among different stakeholder .................................................................................................. 5
Internal and external resources ....................................................................................................................... 6
Suspensions criteria and resumption ............................................................................................................... 6
Responsibilities ................................................................................................................................................ 6
Approvals ........................................................................................................................................................ 6
Page 3
1.
Introduction
One of the fundamental maturity goals of TMM is that to develop goals/policies related to software testing/
debugging and test planning. Theses mature goals mostly managerial in nature and test policy reflect, integrate
and support to achieve these goals.
1.1
Purpose of this document
The purpose of this document within the scope of our Near Real Time Roaming Data Exchange processing
System project is we realizes that testing is an important component of the software development process and
has a high impact on software quality and the degree of customer satisfaction.
1.2
Document organization
The document is organized as follows:
 Section 1, Introduction, describes contents of this test policy document;
 Section 2, Our test policy statement/goals
1.3
Intended Audience
Intended audience is:
• Team members – for testing, fixing bugs, implement changes
• The customer – for checking various functionalities
• The supervisor – to be informed about achievements and system functionality
1.4
Scope
This document contains information about how to ensure that our testing process is effective and that our
software products meet the client’s requirements we have developed.
1.5
Definitions and acronyms
1.5.1
Acronyms and abbreviations
Acronym or
abbreviation
1.6
Definitions
References
1.
.
Practical Software Testing: A Process Oriented Approach. Author: Ilene Burnstein. Publisher:
Springer-Verlag, New York, 2002.
2. Near Real-Time Roaming Data Exchange acceptance test plan document.
2.
Test Policy statement/ goals
2.1
Delivering high quality software product
Delivering quality Near Real-Time Roaming Data Exchange, project is our prime goal. The presence of defects/
errors has a negative impact on software quality. The goal is all testing activities should perform in a systematic
way to support testing process to achieve high quality.
2.2
Testing approach
Testing should be done using Test Plan – all test data should be formed as described in particular case and
preconditions should be fulfilled before testing. Results should be documented and as described in particular
case.
2.3
Testing: What, When and How
Test plan document should include when and how testing done. In our project the following apply regarding
software testing:
 Random test should be perform After performing planned test cases, which should cover regular and
irregular user actions and all features and exceptions, tester should try using the application. Testing
procedure describe when and how to use random test.

Random test of separate module before integration.

Normal test – consists in testing the features trying to cover all the requirements.

Faulty testing – consists in trying to feed the system with strange/invalid values, and see how the
system react.

Integration test – consists in testing modules after their integration in the system.

Stress test – consists in simulating different access and watch if the system performance decrease or if
the system crashes.

Testing activities must be monitored using measurements and milestones to ensure that they are
proceeding according to test plan.

Defects uncovered during each test must be classified and recorded.

All features listed as requirements for all test items will be tested. Test cases are carefully chosen to
cover all functional and nonfunctional requirements.

Conversion process will not be tested because it was not developed as part of NRTRDE project and it
was already tested.
2.4
Communication among different stakeholder



Customer/developer/tester and supervisor communication is important.
All members must be involved in acceptance test planning.
Customer must sign off on the acceptance test plan and give approval for all
Changes in the acceptance test plan by supervisor.
2.5
Internal and external resources


Suspension criteria and resumption
2.6


2.7
All the required hardware and software resources must be provided for continuous test process
improvement.
Installation and configuration of all the necessary products which enable NRTRDE Processing System
to run should be up and good working condition.
Testing can always be paused and continued. In case of a bug, try logging out and in again. If the bug
persists, please contact the NRTRDE Team.
Fixing bugs will not require test process to start all over again. It would test whole testing item where
changes happened.
Responsibilities
Developer responsibilities are:




To read and understand test plan
To read error reports from testers
To fix the bugs existing in the application
To do initial testing of repaired application
User representative responsibilities are:


2.8
To check if the application is fulfilling his needs
Report any error/bug encountered to tester
Approvals
After the test policy has been developed, it must be approved.