Service Switching
SSFSRF ESS
4.3 Basic Test
The primary purpose of the Basic Test is to improve software quality and humanware quality. The Basic Test should detect and eliminate defects as early as possible in the software and humanware life-cycle. Code is checked for conformance to requirements, completeness, consistency and overall correctness. The focus is error detection, rather than correction.
The Basic Test is mainly performed by manual source code checking.
There are three main methods for performing manual code checking. In each case, the used method depends on the complexity of the code.
1 Desk Check/Code Reading - One or more software engineers (other than the author) independently reviews the code. A checklist is used to ensure consistency. The results are documented in an inspection survey and record. If a Desk Test Checklist exists, it can be substituted for the inspection record. Feedback is given directly to the author or at a meeting.
2 Code Walk-through - A review meeting is hosted and moderated by the author. The emphasis is on error detection and the format is flexible.
The participants prepare by reading the code and looking for errors.
The results are documented in an inspection survey and record.
3 Code Inspection - A formal and rigorous inspection process in which defect detection, defect elimination, and correction verification is carried out by a small group during the development life cycle. Code inspections use checklists, preparation, well-defined roles, and
continual process improvement to maximize error-detection efficiency.
The results are documented in an inspection survey and record.
Basic Test execution consists of two phases. In phase 1 individual blocks of implemented code are tested. This phase is called ‘Unit Test’. The second phase focuses on the interface between different blocks of code.
This phase is referred to as ‘Integration test’.
It is important to implement the EST, Emulator Service Test on each Service Design Centre (SDC). The emulator will make the Basic Test much more efficient and a lot of faults would be detected much earlier in the Service Development procedure. That would mean that prototyping would be an important part of the design flow.
A Basic Test must be performed on all new and modified code. Code that may be affected by modifications must also be basic tested.
The elements to test should be described in a checklist. Preferably, this checklist must be generic, in order to re-use it in each project.
Faults found during the Basic Test should be reported in the Basic Test Record. After the designer has corrected the fault(s), a new Basic Test must be performed on the modified code. The modified parts must be identified and re-tested.
The designers are responsible for the complete Basic Test.
4.3.1 Entry Criteria BAT phase 1
The following input is required to start the Basic Test Phase 1:
• The Design Specifications (SSD, AAS, UIS) must be approved.
• Checklists for executing a Basic Test must be available.
• Approved Service Requirement Specification (SRS).
4.3.2 Basic Test SF - Phase 1
During phase 1 of the Basic Test for SF, the designer/programmer should manually check the code (SSLs) by using one of the above described methods. The procedure to use will be decided by the project team during the feasibility study.
The desk check and review focus on the implementation of one SSL. The integration between SSLs is not formally tested. This is within the scope of the second phase of the Basic Test.
Aspects to consider when desk checking and reviewing a SSL, are:
• Are the correct register numbers used?
• Are the correct data types used?
• Is each variable assigned a value before it is used?
• Are all outlets handled correctly?
• Is the design efficient in terms of SIBs and CDMs?
The test is performed by deskchecking the Service Script Description (SSD) and the Service Function Specifications (SFS). What to check is specified in a checklist.
A Basic Application Test Report, BATR, should be prepared including both test cases and the result of them. Each feature should be tested with the Red Line Trace tool. The BATR should be used as input when preparing the SAT test specifications.
4.3.3 Basic Test SMS - Phase 1
During phase 1 of the Basic Test for SMS, the designer/programmer tests the implemented code. This can be, for example, one window, a procedure, a function or a class. The test concentrates on an isolated block of code. The integration between blocks of code is not formally tested. This is within the scope of the second phase of the Basic Test.
Aspects to consider when desk checking and reviewing a procedure, func-tion, script or class, are:
• How does this correspond to the customer needs and wishes?
• Are the Design Rules and Guidelines followed?
• Is the implementation according to the Design Specification?
• Is the program divided in suitable parts for readability and mainte-nance?
• Is the received input used?
• Is the right output generated?
The test can be performed by desk checking and reviewing the imple-mented code or by compiling the code and then executing the compiled code.
Testing the windows of a Graphical User Interface can be split in two parts:
• Coverage Test
• Compliance Test
• Usability Test,
During the coverage test, the designer/programmer starts of by systemati-cally running through as many actions, i.e. menu selections, button push, tick box, etc., as possible.
The compliance test consists of using a checklist to verify that the Graph-ical User Interface (GUI) complies to given guidelines.
The usability test verifies if the GUI meets the Usability Goals which have been defined in the feasibility study.
During phase 1 of the Basic Test SMS, the following areas should be covered when testing each separate window:
• Does the window conform to the SMS Design Rules?
• Do fields on the window behave in the right way (minimum and max-imum value, length)?
• Do buttons and menu options react in the right way?
• Is help text available for every field? Is the text complete and correct?
• Configuration and set-up files should be deskchecked.
The test can be performed by deskchecking and/or executing the imple-mented code.
A checklist specifies the elements to be checked. Such a checklist must be made for every component of the management system. The checklist must be generic, to enable re-use.
4.3.4 Basic Test UI - Phase 1
During phase 1 of the Basic Test for UI, the information designer and repre-sentatives of the SF and SMS groups review the different customer docu-ments.
The scope of this test phase is to check whether the information in the docu-mentation is correct and complete and whether the docudocu-mentation
conforms to the Design Rules and Guidelines.
Access to the management system will help when reviewing the documen-tation. However, access to the management system is not required.
Aspects to consider when desk checking and reviewing the customer docu-mentation, are:
• Are the UI Design Rules and Guidelines followed?
• Is the implementation in accordance with the UIS?
• Are descriptions correct (review by SF and SMS)?
• Do the field characteristics comply with SMS specifications?
A checklist must be made stating the aspects to review. The checklist must be made as generic as possible, to enable re-use.
Review remarks are indicated on the checklist or in an inspection record.
The information designer is responsible for updating the documentation.
After the update, the updated parts should be reviewed once more.
4.3.5 Exit Criteria
The following exit criteria must be met to finalize the Basic Test Phase 1:
• All new and modified code must have been basic tested.
• All ‘testcases’, as listed in the checklist, must be passed.
4.3.6 Basic Test - Phase 2
To support a structured integration test, a test specification containing all test cases must be available. A detailed Test Instruction is not required for this test phase.
4.3.7 Entry Criteria
The following input is required to start the Basic Test Phase 2:
• Basic Test environment and tools must be established and verified.
• The Design Specifications (SSD, AAS, UIS) must be approved.
• Approved Test Specifications for executing phase 2 of the Basic Test must be available.
4.3.8 Basic Test SF - Phase 2
The second phase of the Basic Test will verify that interfaces between components are correct and that the components interact according to the design. This test phase is typically carried out in steps, where increasingly larger components are integrated.
First, all SSLs making up one feature are combined to be tested. Then all features making up one service are combined to be tested.
This test focuses on whether the service is executing a call in the right way, meaning that the right flow is followed through the features. However, note that the scope of this test is limited to some major functional flows. Not all possible flows are expected to be tested.
The Red Line Trace should be used for this test phase. By defining a number of different subscriptions and specifying input data, it can easily be tested whether the right sequence is followed. Blocking faults in the service and/or in one of the features can be discovered in this way.
Testing of the feature should focus on all major functional flows. To ensure a structured performance of the Integration Test, a Test Specification must be available (included in the BATR), stating all test cases to be executed.
4.3.9 Basic Test SMS - Phase 2
Phase 2 of the Basic Test for SMS focuses on the interaction between different software blocks. All procedures, classes, functions, windows forming a complete Service Management System should be integrated tested.
Testing components consisting of procedures, functions and/or classes should focus on:
• Usability goals fulfilled?
• Are the Design Rules and Guidelines followed?
• Is the implementation of the component according to the Design Spec-ification?
• Is the right input received from either a procedure/class/function or an-other component?
• Is the right output generated by the component?
The test can be performed by compiling the code and then executing the compiled code.
The test of the (Graphical) User Interface should focus on:
• Consistent lay-out and behaviour of the windows
• Data correctly inherited from other windows
• User-friendly and easy-to-use management system
• Help-text consistent and helpful
To test the GUI, a User Information designer should be involved to check the GUI on user-friendliness, consistency and ease-of-use.
The way all components should behave is described in the design specifi-cation. This specification can be used as input for the test cases, specified in the Test Specification.
4.3.10 Basic Test UI - Phase 2
Phase 2 of the Basic Test for User Information consists of a review of consistency between the User Information Objects. The User Information Objects are also checked to ensure correctness, completeness and consist-ency. A generic checklist must be created for this purpose.
Aspects to focus on when desk checking and reviewing the customer docu-mentation are:
• Usability goals fulfilled?
• The customer’s needs and demands fulfilled?
• Are the UI Design Rules and Guidelines followed?
• Is the structure of the documentation clear?
• Are the typography and lay-out consistent throughout all documents?
• Are illustrations consistent throughout all documents?
4.3.11 Exit Criteria
The following exit criteria must be met to finalize the Basic Test Phase 2:
• All new and modified code must be basic tested.
• All testcases, as mentioned in the Test Specification, must be passed.
• Basic Test Report must have been prepared.