NRTRDE Processing System

SVN Policy

Version 1.0

Doc. No.:
NRTRDE Processing System Version: 1.0
SVN Policy Date: 2010-01-08

Revision History

Date Version Description Author

2010-01-08 1.0 First version Muhammad Siddique

Page 2
 NRTRDE Processing System Version: 1.0
SVN Policy Date: 2010-01-08

Table of Contents
1. Introduction..........................................................................................................................................................4
1.1 Purpose of this document..................................................................................................................................4
1.2 Document organization.....................................................................................................................................4
1.3 Intended Audience.............................................................................................................................................4
1.4 Scope.................................................................................................................................................................4
1.5 Definitions and acronyms.................................................................................................................................4
1.6 References.........................................................................................................................................................4

2. Test policy statement/goals..................................................................................................................................5

2.1 Delivering high quality software product.........................................................................................................5
2.2 Testing approach...............................................................................................................................................5
2.3 Testing: what,when,how....................................................................................................................................5
2.4 Communication among different stakeholder...................................................................................................5
2.5 Internal and external resources........................................................................................................................6
2.6 Suspensions criteria and resumption................................................................................................................6
2.7 Responsibilities.................................................................................................................................................6
2.8 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
Definitions
abbreviation
NRTRDE Near Real-Time Roaming Data Exchange, project name

TMM Test Maturity Model

1.6 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

 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.

2.6 Suspension criteria and resumption

 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.

2.7 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:

 To check if the application is fulfilling his needs

 Report any error/bug encountered to tester

2.8 Approvals
After the test policy has been developed, it must be approved.