Telecom domain
is one of the hottest domains around. Testing in Telecom is an automated,
controlled method of verifying operation of your products before they go to
market. As operators begin to add new
networks and expand existing network to support new technologies and products,
standardizing bodies are coming up with models, tools and methodologies for
design and development. Testing strategies have not evolved with technology and
they still rely on Legendry models Waterfall, V and a prospective testing model
which is not best suited for the telecom industry. Testing in telecom domain is
much more complicated than other domains in terms of environments, hands off
and technology.
Another
important factor influencing the requirement for a proper telecom testing are
the mergers and acquisitions among key vendors. Ease of integration in critical
and requires a holistic view of telecom testing. These requirements trigger the
need for new strategies in telecom testing.
Testing in Telecom
Telecom
lifecycle is different from the software lifecycle and a testing strategy based
on the telecom lifecycle is required to address the issues challenges. V and
proactive testing models do not address the challenges of telecom end-to-end
business in the converged world as it is non-standard and lacks a common
industry acceptance. Issues in telecom testing are taken up in more detail as
challenges under each phase of telecom lifecycle.
Any customer
request or service development / enhancement can be categorized as a business
requirement. The testing lifecycle starts once the business requirement is
analyzed. Once a decision is made on developing the requirement, testing then
moves to the system / architecture phase where the service developer works on
defining a technology- neutral method of implementing the requirement. This is
followed by the Implementation phase where the requirement is implemented. The
implementation phase in itself would involve certain amount of integration of
the component developed in stages. The major phase where a telecom-based
testing pays off is in the deployment phase 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 phases
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 zero failures during operation. The test
artifacts developed in different phases can be test plan, test case or even a
test model for the specific telecom scenario.
Business Phase of Testing Lifecycle
This phase handles
investigation of the requirements and Proof of Concept before taking up the
requirements. The investigation of the requirements starts with elicitation and
ends with specification.
Challenges
1.
Issues at any stage of the
requirements investigation leading to product development not meeting actual
business requirements. Some examples of the issues that can happen are:
a. Requirements handoff to service developers in stages or
partially due to pit holes in elicitation, without understanding the impact of
providing a detailed set of requirements.
b. Requirements creep like continual addition and change of
requirements.
c. Inability to identify the real business requirements.
2.
PoC developed by a Service
Provider does not meet the actual infrastructure of the Service Developer.
3.
Lack of analysis of the business phase
documents or not making the requirements explicit to best cater to a
heterogeneous network, multiple service, and multi-vendor environment.
4.
Not considering the impacts of
the operation and maintenance of the developed product that meets the
requirement.
Resolution
1.
Make requirement based test
cases. However, these may not be sufficient as a requirement can be invalid,
yet still be testable.
2.
Define acceptance criteria during
the requirement phase. An acceptance criterion does not just come from the
defined requirements. Instead, it comes from a testing perspective and can help
to identify incorrect requirements.
System / Architecture Phase of Testing Lifecycle
This stage
involves testing the system / architecture developed and the prototype based of
the same.
Challenges
1.
Analysis of telecom standards for
developing the specified business case is not considered.
2.
Business Phase testing was
incomplete or not properly executed.
Resolution
1.
Simulation / Virtual prototyping
– Building an executable model or prototype of design for simulation. That
model is used to verify and test various elements of the entire system design.
2.
Ensure that system and business
requirements are based on telecom standards and implementation outline will
help to implement the product without any ambiguity.
Implementation Phase
Implementation
of service or parts of the service takes place at this stage. This phase is
still limited to a single vendor though that vendor may have suppliers and
partners who assist with the implementation.
Challenges
1.
Third party applications can
affect the functioning of the product
2.
Actual environment in terms of
actual traffic is not available
3.
Interoperability issues
Resolution
1.
Third party tools should have
well defined interface descriptions as well as the shared information and data
model it supports which should be well evaluated when selecting these tools.
2.
There are many companies who have
products that can simulate actual traffic at core network, access as well as number
of user nodes. Service developers should also buy / lease these products and
effectively test reliability as well as quality offered by the components
developed in implementation phase.
3.
Moving to open standards and
products that interoperate well with legacy systems and at the same time, work
as independent units can go a long way to improving interoperability and
interfaces with the legacy systems.
Deployment Phase
The actual
integration for the live operation of the service / product occurs in this phase.
This is the multi-vendor environment which is now a critical phase in current
telecom industry with converged networks and services.
Challenges
1.
Lack of a standardized telecom
testing model covering end-to-end telecom lifecycle
2.
Immature guiding templates,
contracts and models for test progress
3.
Non-standardized and proprietary
language in defining telecom test-related artifacts
4.
There is no standardization in
testing tools to test for compliance of standards and policies
5.
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 a backbone
2.
Standard bodies to work on
developing templates and contracts for test artifacts
3.
Testing tools should be defined
and developed at the implementation phase to check for compliance to standards,
policies and interfaces
4.
Test artifacts and test results
from the business, system and implementation phases to provide inputs to the
deployment phase for identifying effective interoperability with other products
5.
Enough emphasis and standards for
testing to be defined along with bodies that validate and certify the approach
The higher
degree of complexity accompanying the telecom technology necessitates testing
strategies that can create and deploy new service offerings with a higher
degree of flexibility and a shorter time-to-market, while staying at the
competitive edge in rolling out new, compelling service with improved customer satisfaction.
This requires a holistic view to telecom testing life cycle which can be
achieved using above lifecycle as backbone to define the testing lifecycle.
