By Rohit Aggarwal

Testing in telecom world is as vast a subject as the domain itself. This blog talks about the readiness to become a telecom tester. The intent is to address the apprehensions and misconceptions; the actual tools and methodologies involved form the next level of discussion.

Kick-start
Do not jump to the System Under Test (SUT). Start from the bigger picture.
For instance, understand the technological domain/network, then the network nodes, then the SUT as a black box.

W5H of the System Under Test
There is a lot of food for thought. It is important to answer a few questions to be able to prepare the use cases and test details.
i. What does it do: functionality
ii. Where is it placed: network positioning
iii. Why is it needed: network architecture, business drivers
iv. Who will use it: end user – could be human being or another network node
v. When is it used: time, service, peak usage etc.
vi. How does it work: protocol, language, interfaces

Knowledge of deployment zone is a value-add. Test criteria needs to consider regional policies, infrastructure and usage patterns.

Documentation
A lot of information about the SUT is available through
 Technical specifications sheet
 Release bulletin
 User Manual
 Requirement Specifications
and other technical documents.

Types of Testing
There are multiple behavioral elements of the SUT that need to be tested.
 Functional
 Compliance
 Performance
 Load
 Soak

One of the key facets is that most of the telecom equipment is real-time.

Test Environment
Test tools can be
 Purchased: cost-driven
 Produced: time-driven
 Procured: contract-driven

Investment
 Ramp up
 Time: large amount of time needed to understand the technical specifications
 Cost: almost entire knowledge base freely available on web
 Test bed
 Time: to code test stubs
 Cost: to buy test stubs e.g., OS, compiler, network software, equipment