Service Application Test procedure

Figure 4.5

SAT test procedure Documents

SAT Execution SAT Planning

SAT Instruction SAT

Preparation

SAT

Specification

SRS AFS UFS

SRS TER Project Spec.

SATS

TOL

SATI

Test Report

SATR updated

Installation Instruction SAM SATP

SA product

Installation Instructions SF

Test Planning

Within this activity, the basis for Service Application Test (SAT) is

defined. This implies descriptions of tools to be used (for example simula-tor/emulator), test reports to be written and personnel required for testing.

An analysis is made of the requirements and other preconditions which will affect the scope of SAT. In addition to the Service Requirement Spec-ification (SRS), check the general test aspects that have been considered in the TEchnical Report (TER) during the prestudy phase.

To plan for SAT, a number of issues have to be considered:

• Test analysis giving the scope of test, estimation of man-hours for test design and execution, estimate time and resources for Test Configura-tion Management (TCM), specify if tests are excluded and subjects for special attention.

Note: Should some performance tests not be possible to execute in SAT due to HW limitations, this must be communicated to the Network Inte-gration Test (NIT) test as early as possible!

• Initial TCM activities including test plant booking where requirements on AXE SW, AXE HW, SMAS environment and other environments must be specified. This is a critical activity which must be initiated as early as possible in order to get access to a testsite with the proper setup.

• Test decision where the object is to:

- Decide the scope of the tests that are to be performed.

- Approve the cost estimate for the tests.

Input

Service Requirement Specification, SRS TEchnical Report, TER

Project information Output

Service Application Test Plan, SATP

SAT Specification

The purpose of the Service Application Test Specification (SATS) activity is:

• To give an overview of the test environment, necessary equipment, test tools and their usage.

• Specify the test configuration and indicate if any deviations from a standard SAT configuration are required.

The way to perform each test case defined in the SAT plan shall be described and compiled into a SAT Specification where each test case is

• Requirement based test to verify behaviour and performance as stated in the requirements.

• Design based test to verify changes made to the SF, SAM and UI parts not related to any requirement.

• Miscellaneous test to verify aspects not covered in requirement based or design based tests, e.g. user friendliness.

In addition to the Service Application Test Specification (SATS), a Test Object List (TOL) used for checking the progress during test execution should be created. The TOL is a matrix with each test case against all rele-vant information for that test case.

Input

Service Application Test Plan, SATP Service Requirement Specification, SRS Service Function Specification, SFS

Administration Function Specification, AFS User information Function Specification, UFS Output

Service Application Test Specification, SATS Test Object List, TOL

SAT Instruction

The purpose of a Service Application Test Instruction (SATI) is to give a detailed, step-by-step description of how each test case should be exe-cuted, and the expected result of each action. Depending on the complex-ity, several SAT instructions may be created.

Each SAT instruction should also contain information about the test envi-ronment, part of the exchange configuration involved, and manual prepa-rations or modifications needed. All modifications must be restored after the test.

Input

Service Application Test Specification, SATS Test Object List, TOL

Output

Service Application Test Instructions, SATI

For an example of what the content list of a SATI would look like se figure 1.6, figure 1.7. shows an example of a test case layout according to MIND:

Figure 4.6

SATI content list example

Freephone Contents 1

Preparations 1.1

Test Environment 1.2

Data for loading of Freephone 1.3

Data for removal of Freephone 2

Requirement-Based tests 2.1

Ordinary calls (Successful calls) 2.2

Ordinary calls (Unsuccessful calls) 2.3

Modification calls (Successful calls) 2.4

Modification calls (Unsuccessful calls) 2.5

Call for access to other services (Successful calls) 3

Design based tests 3.1

Normal user reactions 3.2

Abnormal user reactions 4

References

Figure 4.7

A Test case example SAT Preparation

The objective of Service Application Test (SAT) preparation is to setup the test plants in accordance with the SAT plan. This includes AXE, SAM-servers, workstations, and other HW needed in addition to the standard setup.

The setup should be conducted using correct versions of AXE software and SMAS. Exchange data should be loaded (and modified if necessary), parameter corrections and service related corrections should be loaded.

All test tools specified shall be made available.

Before the preparation is ready, the basics shall be verified, for example by making some test calls.

Input

Service Application Test Specification, SATS Service Application Test Plan, SATP

Output

Test site ready for execution 2.1.1 Successful call - connection to 800011

ACTION: Dial the access number for the service 30 12345678.

RESULT: The phone with the number 800011 rings.

ACTION: Answer the phone and check that you are in speech position.

RESULT: Speech path okey.

ACTION: Onhook all phones and check that no devices are hanging:

> TOBJI:ALL;

RESULT: No devices are hanging.

COMMENT:

-Calls from one of the A-numbers 1-4.

Make sure that 800011 will be chosen by the load distribution function.

SAT Execution

During test execution, the progress should be monitored by the Test Man-ager, who also reports to the main project. Operative decisions concerning the test execution are made by the Test leader. Please note that it is not only the functions and characteristics of the service that should be tested, but also instructions such as Installation Instructions.

The exchange data files should be stored and a Service Application Test Report should be written. When the SA product has passed the service application test and all product documents have been updated, they are stored in GASK.

It is important that experiences and opportunities for improvement are identified and described before the SAT execution activity is finished.

Input

SA product

Installation Instructions, II (SF) Installation Instructions, II (SMS)

Service Application Test Instructions, SATI Test Object List, TOL

Service Application Test Plan, SATP Output

Service Application Test Report, SATR