You are on page 1of 6

NRTRDE Processing System

SVN Policy

Version 1.0

Doc. No.:

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.

............................................................................................................................................................................................................................................4 Communication among different stakeholder.............................................4 1.............................................................................2 Testing approach..........................6 2...........................................................................................................................................................................................4 Scope......................................1 Purpose of this document........................3 Intended Audience..........................................................5 2.............................5 2....................................................................................................................................3 Testing: what.........6 References........4 1...........................................................................4 2...........5 2.................................................4 1......4 1..................................... NRTRDE Processing System Version: 1........................6 2.............................................................................................................................................................8 Approvals ............................................................................4 1.....................6 Page 3 .............how................................................5 Internal and external resources..................................6 Suspensions criteria and resumption......................................................................................................................................................when....................................................... Introduction...............................................................................................4 1.................................................................5 2..........1 Delivering high quality software product..........................0 SVN Policy Date: 2010-01-08 Table of Contents 1.........5 Definitions and acronyms...................2 Document organization.......................................................................6 2............................................................5 2...................................................... Test policy statement/goals..........................7 Responsibilities....................................................................................................

Author: Ilene Burnstein.6 References 1.1. 1. Theses mature goals mostly managerial in nature and test policy reflect.  Section 2. New York.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.2 Document organization The document is organized as follows:  Section 1. Introduction. 1. Our test policy statement/goals 1. Near Real-Time Roaming Data Exchange acceptance test plan document. . 1.5 Definitions and acronyms 1. project name TMM Test Maturity Model 1. Publisher: Springer-Verlag. implement changes • The customer – for checking various functionalities • The supervisor – to be informed about achievements and system functionality 1.3 Intended Audience Intended audience is: • Team members – for testing. fixing bugs. 2002. Introduction One of the fundamental maturity goals of TMM is that to develop goals/policies related to software testing/ debugging and test planning. 2.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. describes contents of this test policy document.1 Acronyms and abbreviations Acronym or Definitions abbreviation NRTRDE Near Real-Time Roaming Data Exchange.Practical Software Testing: A Process Oriented Approach. .5. integrate and support to achieve these goals.

which should cover regular and irregular user actions and all features and exceptions. Testing procedure describe when and how to use random test.  Stress test – consists in simulating different access and watch if the system performance decrease or if the system crashes. 2. . Test cases are carefully chosen to cover all functional and nonfunctional requirements. Results should be documented and as described in particular case.  All features listed as requirements for all test items will be tested. 2.  Integration test – consists in testing modules after their integration in the system.  Random test of separate module before integration. Test Policy statement/ goals 2.  Conversion process will not be tested because it was not developed as part of NRTRDE project and it was already tested. project is our prime goal.4 Communication among different stakeholder  Customer/developer/tester and supervisor communication is important.1 Delivering high quality software product Delivering quality Near Real-Time Roaming Data Exchange.  All members must be involved in acceptance test planning.  Testing activities must be monitored using measurements and milestones to ensure that they are proceeding according to test plan. When and How Test plan document should include when and how testing done. tester should try using the application.2.  Faulty testing – consists in trying to feed the system with strange/invalid values.  Customer must sign off on the acceptance test plan and give approval for all Changes in the acceptance test plan by supervisor.3 Testing: What. and see how the system react. The presence of defects/ errors has a negative impact on software quality.  Defects uncovered during each test must be classified and recorded.  Normal test – consists in testing the features trying to cover all the requirements. The goal is all testing activities should perform in a systematic way to support testing process to achieve high quality. 2. In our project the following apply regarding software testing:  Random test should be perform After performing planned test cases.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.

In case of a bug.2. it must be approved. If the bug persists. It would test whole testing item where changes happened.8 Approvals After the test policy has been developed. 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.6 Suspension criteria and resumption  Testing can always be paused and continued.  Installation and configuration of all the necessary products which enable NRTRDE Processing System to run should be up and good working condition. . please contact the NRTRDE Team.5 Internal and external resources  All the required hardware and software resources must be provided for continuous test process improvement. try logging out and in again. 2.  Fixing bugs will not require test process to start all over again.