Monday, October 13, 2008

Telecom (Convergence) Testing Model - Part 2

Telecom lifecycle is different from the software lifecycle hence testing strategy should be different and based on requirements to address the issues of converged space first. Existing V or X and other proactive testing models do not address the challenges for end-to-end telecom business solution. Ideal Telecom testing model should fit in multi vendor specific devices in converged space with a common industry acceptance or standards.

The above telecom testing lifecycle is based on the NGOSS telecom lifecycle defined in GB927. Conceptually the NGOSS Lifecycle process is similar to ISO 9001/2 where the standards describe what processes must be in place and what the requirements are on those processes at a high level. However the exact way those processes are realized can vary, provided that they meet the minimum requirements set out in the standard.

NGOSS or "New Generation Operations Systems and Software" is the TeleManagement Forum’s programme to provide ways to help Communication Service Providers to manage their business.

"Any customer request or service development/enhancement can be categorized as a business requirement. The testing lifecycle starts here when the business requirement is analyzed. Once a decision is made on developing the requirement, testing now moves to the system/architecture view where the service developer works on defining a technology neutral method of implementing the requirement. This is followed by the Implementation view where the requirement is implemented. The implementation view in itself would involve certain amount of integration of the component developed in stages. The major view where a telecom based testing pays of is in the deployment view where multiple implementations are integrated during deployment. In a multi service heterogeneous multi vendor environment, the test artifacts and their execution results for the other views serve as input to generation of deployment artifacts that result in providing new service
offerings with a higher degree of flexibility and a shorter time-to-market with minimal or nil failures during operation." - Abstract from "Telecom Testing and Convergence" by Jithesh Sathyan of Infosys Technologies Limited, India.

So what can be test artifacts, it can be anything like test - bed /data/ plan/ case/ tool/ log/ script/ models/ reports for the specific telecom scenarios.




Here we will see the challenges and resolution on two most testing oriented views - Implementation and Deployment.

A. Implementation View

Challenges:

1) Insufficient tools available to test the interfaces between different components.
2) Dependency with third party applications can affect the product functioning.
3) Actual environment and actual traffic unavailable.
4) In legacy systems, there is always some dependency on lower components. Unless lower components are available, you cannot test the higher components independently.
5) Interoperability issues

Resolution:

1) The Implementation view should also look into development of tools to test interfaces for functionality as well as compliancy to standards.
2) Third party tools should have well defined interface description as well as the shared information and data model.
3) Use best available simulators / emulators.
4) Migrate to open standards and products which interoperate well with legacy also.

B. Deployment View

Challenges

1) Standardized telecom testing model covering end-to-end telecom lifecycle is lacking.
2) Non-standardized and proprietary language in defining telecom test related artifacts.
3) No standardization in testing tools for compliance testing of standards and policies.
4) No testing benchmark exists today that can be used for end-to-end lifecycle validation.

Resolution

1) Follow the telecom lifecycle approach in testing which uses NGOSS lifecycle as backbone
2) Standard bodies to work on developing templates and contracts for test artifacts
3) Testing tools should be defined and developed at implementation view to check for compliance to standards, policies and interfaces.


How NGOSS Concept can help?

Step 1) The eTOM (enhanced Telecom Operations Map, pronounced ee-tom) is the NGOSS business process framework.

Step 2) Map telecom process with eTOM and Analyse the resource requirements. Map TAM (telecom application map) on testing specific applications.

Step 3) Define the test artifacts based on shared information and data (SID) and map.

Step 4) Map TMF artifacts for developing test artifacts for specific requirements.

So, when we are done with detailed Mapping of testing to NGOSS concepts of eTOM, TAM, SID and TNA and generation of test artifacts. Analysis can be performed to understand how and if system models and processes align with the NGOSS frameworks.

There are few companies which are working and have products for the same. One of them is Metabula. Metabula have extended their NGOSS conformance solution (with analysis) for SID framework to include cross referencing with eTOM framework.

Sources:
http://www.tmforum.org/browse.aspx
http://www.metabula.com/details/schemaanalysis.html
http://en.wikipedia.org/wiki/NGOSS

No comments:

Post a Comment