How to speak so that people want to listen

The paradox of choice

Have we reached the end of physics? | Harry Cliff

Telecom Mediation

Introduction to Telecom Mediation

What is Mediation?

n  The Mediation System provide a reliable way to collect usage information from the network, distributes the data to billing system, with no missing data and thus support the management of Call Data.

n  Mediation involves data transfer between various systems with or without modification of data starting Network elements to OSS/BSS systems

n  Mediation system "mediate" between a varieties of other systems.

n  The upstream systems (those providing data to the mediation platform) are network elements, such as telephone switches, and the downstream systems (those receiving data from the mediation platform) perform accounting, auditing, archiving, or bill-generation functions.

n  The mediation system collects, collates and prepares data for consumption by the downstream systems, which often accept data only in a limited set of formats.

n  A billing mediation platform is a system used to convert data types of a certain type to other data types, usually for billing purposes;

n  Provides an easy-to-manage, single point of interface to the network.

n  Provide link between the network and the IT applications (Billing System, Fraud Management System, Data Warehousing System, etc).

Why Mediation is required?

n  Billing is a complex process, starting from the network elements, which generate all the usage data. It primarily involves data collection, format adaptation, rating and invoicing.

n  In today’s networks there are multiple sources for charging records.

n  Each billable usage of the network (or service platform) has to be recorded and charged.

n  These records, which are produced by the network elements, are generally known as Call Data Records (CDR) in traditional voice networks (fixed or mobile), Usage Data Records (UDR), or Event Data Records (EDR), IPDR in case of broadband usage, and more generally “xDR” in new networks.

n  There is a need to collect charging information from many different network elements in order to provide subscribers with a single bill for all the services they use.

Why Mediation is Important?

n  The concept of “one bill for all services”, which is being demanded by subscribers, is not be easy to achieve because not all the services are provided by the access provider. The intelligence is needed to construct a common bill from information provided by several independent platforms will require high flexibility, in terms of collecting any type of data, handling various protocols, storing partial information while waiting for the missing parts before performing a correlation, etc.

n  It is important to include mediation facilities in networks to seamlessly provide adaptation for new and changing sources of information, and as a 'pre-processing' layer to minimize the impact on the billing system of adding new services.

What does Mediation System do?

n  Network data usage collection (CDR, IPDR,) 

n  Data Collection on switches, VAS platforms, gateways, Radius 

n  Data validation and filtering out of non billing-relevant CDRs

n  Collating

n  Correlation of different input sources CDRs

n  Aggregation of partial CDRs related to the same call

n  Format change and CDRs normalization

n  Business transformation of data

n  Reformatting and enhancement 

n  Splitting, sorting and distribution to various OSS or BSS Applications 

Mediation System: Architecture

n  Collector

      It is responsible to collect all types of usage data (Voice, Data, SMS, Content, Video etc.) from all kinds of upstream systems like TDM Switches, NGN Switches, and Gateways etc. It has multiple nodes and each node can be configured with different types of usage data source.

n  Processor

It processes data according to the rules defined by the users. Processor performs three tasks, filters data properly through customized filters, remove any type of duplication from the data and modify it as per the requirements.

n  Distributor

It supplies the needed information to the downstream systems. It distributes usage data to different sources like text files, Excel files, CSV file, Binary file, RDBMS etc.

Challenges           

n  The challenge of billing mediation is not as simple as it seems. There is a need for protocol handling, format adaptation and complex processing. This class of mainly software-based solutions has to deal with both network equipment (telecom world) and computers (information systems), adding some complexity. In addition, scalability and the ability to cope with the storage and processing of several hundred million CDRs every day are essential for today’s biggest operators. 

Testing in Telecom

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.

The case of poor Boundary Value Analysis

In September 2005, a man living in Gurgaon near New Delhi, India, received a bill for his as yet unused credit card stating that he owed Rs.0/-. He ignored it and threw it away.

In April, he received another and threw that one away too.

The following month, the credit card company sent him a very nasty note stating they were going to cancel his card if he didn't send them Rs.0/- by return of post. He called them and talked to them; they said it was a computer error and told him they'd take care of it.

The following month, our hero decided that it was about time that he tried out the troublesome credit card figuring that if there were purchases on his account it would put an end to his ridiculous mess. However, in the first store that he produced his credit card in payment for his purchases, he found that his card had been cancelled.

He called the credit card company who apologized for the computer error once again and said that they would take care of it. The next day he got a bill for Rs.0/- stating that payment was now overdue. Assuming that, having spoken to the credit card company only the previous day, the latest bill was yet another mistake, he ignored it, trusting that the company would be as good as their word and sort the problem out.

The next month, he got a bill for Rs.0/- stating that he had 10 days to pay his account or the company would have to take steps to recover the debt.

Finally giving in, he thought he would play the company at their own game and mailed them a cheque for Rs.0/-. The computer duly processed his account and returned a statement to the effect that he now owed the credit card company nothing at all.

A week later, the man's bank called him asking him what he was doing writing a cheque for Rs.0/-. After a lengthy explanation, the bank replied that the Rs.0/- cheque had caused their cheque processing software to fail.

The bank could now not process ANY cheques from ANY of their customers that day because the cheque for Rs.0/- was causing the bank's computer to crash.

The following month, the man received a letter from the credit card company claiming that his cheque had bounced and that he now owed them Rs.0/- and unless he sent a cheque by return of post, they would be taking steps to recover the debt.

The man, who had been considering buying his wife a computer for her birthday, bought her a typewriter instead :)

What is B2Bi ??

Business-to-Business integration (B2Bi) is not a new concept and in fact many Information technology organisations have been running B2Bi projects since the late 1960’s.  Simply put B2Bi means the integration, automation and optimisation of key business processes that extend outside the four walls of a companies organisation.  While these critical processes vary by vertical, geography and company size one point remains consistent, the automation of key external business processes, those that touch your customers and your suppliers delivers sustainable competitive advantage. 

For example receiving purchase orders from your customers electronically, you can process order information faster and more accurately.  Processing these orders in real time allows companies to be more responsive to their customers, improve customer service and increase sales.  Similarly, by connecting to external suppliers electronically, companies can achieve real time views into the visibility of global shipments, automating the warehouse or distribution centres and optimising inventory or stock control – ultimately increasing working capital and lowering costs. 

B2Bi began with large companies mandating methods of receiving business information technology.  It evolved through the widespread adoption of Electronic Data Interchange (EDI) and in recent years has benefited from technology innovations e.g. the advent of the Internet, XML, web services and SOA, Business Process Management and SaaS.  These innovations have led to increased benefits being made available to companies of every size.  As we explore in this Microsite there are a number of ways to implement B2Bi solutions.  We discuss that the solution approach should be driven by a company’s business needs and objectives, rather than a particular implementation or technology set.

B2B Definition

In today’s fast-paced business world, your organisation may already be moving in this direction, customers or suppliers may already be approaching you to integrating and automating key business processes.  For the newcomer to B2Bi, it may seem a very confusing subject area.

B2Bi Basics

So what components make a B2Bi solution?  In short a B2Bi must facilitate successful and cost effective electronic exchange of business data and the integration of external business processes.  Any B2Bi solution must comprise of the following components.

• Electronic Data Exchange – the automation of key business documents (e.g. Purchase Orders, Shipping Notices, Invoices etc).  Essentially replacing key shared paper documents with real time exchange of electronic files.   
• Business Process Management – the use of rules and profiles to improve and cleanse the quality of key business documents (e.g. matching delivery quantities provided in an invoice to the goods received or shipping notice).  Helping companies improve the accuracy of information for back office processing.
• Business Activity Monitoring – applications, typically delivered online, that monitor the real time status of B2Bi operations and report performance over a given time period (e.g. alert me when I receive a Purchase Order over £10,000 in value).  Alerts help companies improve real time process breakdowns and reports offer the chance to strategically improve performance over time.
• Global Partner Enablement and Management – tools that allow companies to effectively automate connections from their global partners (e.g. Customers, Suppliers, Logistics Providers, Financial Institutions). This critical component of a B2Bi solution is fundamental to the success of every B2Bi solution.

B2Bi is the logical extension of internal business integration projects, ensuring that internal investments made for process automation are extended to customers and suppliers.  In recent years the proliferation of technology and deployment models have resulted in increasing complexity.  The overwhelming factor in choosing B2Bi solutions is to select scalable, flexible, feature rich solutions that deliver a return on investment whilst also ensuring tomorrows requirements can be supported.

Before learning more about a B2Bi solution, it is important to look at an example that highlights some of the key differences between traditional paper document transactions and B2Bi.  One of the first places where many companies implement B2Bi is in the exchange of a purchase order (PO).  In the traditional method of processing a purchase order, a buyer or purchasing agent will go through a fairly standard procedure to create a purchase order, consisting of the following steps:

• A buyer reviews data from an inventory or planning system
• The buyer enters data into a screen in the purchasing system to create a PO
• The buyer waits for the PO to be printed, usually on a special form
• After the PO is printed, the buyer mails it to the vendor
• The vendor receives the PO and posts it in their order entry system
• The buyer calls the vendor periodically to determine if the PO has been received and processed

When you add up the internal processing time required by the sender and receiver, and then add a couple of days in the mail, this process normally takes between three and five days.  This assumes first that both the sender and receiver handled the PO quickly and that at every point along the way there were no errors in transcribing data from a form to a system.

B2B Definition - Why B2B?

Now consider the same document exchange when a company places its purchase orders electronically using B2Bi:

• The buyer reviews the data and creates the PO, but does not print it
• B2Bi solution creates an electronic version of the PO and transmits it automatically to the sender within minutes
• The vendor’s order entry system receives the PO and updates the system immediately upon receipt

What took up to five days with paper and the postal system has just taken less than one hour.  By eliminating the paper handling from most of the stages of the process, B2Bi has the potential to transform a traditional paper based process to look like this:

B2Bi Dynamics

Before discussing the potential B2Bi solutions, it’s important to review three key principles that make B2Bi unique. 

1. The role of standards.  Much work has been completed in multiple industries to foster supply chain integration and create business standards which accelerates and eases the deployment of B2Bi technology.  While we cannot underestimate the important work of these standards bodies we must also appreciate the fact that companies will continue to sub-optimise their supply chains, meaning that no two organisations will implement the standard in the same way.  For example grocery retailers in Europe are likely to leverage the EDIFACT standards for purchase order and invoice automation.  However, because each grocery retailers process may very subtlety in nature, they may implement the standards in different ways, using making one conditional field mandatory where others may choose to leave it conditional.  This sub-optimisation of supply chain processes means that the standards will continue to be implemented differently.  A B2Bi solution must have the configuration and flexibility to support such sub-optimisation of industry standards.
2. Technology Proliferation.  Again because B2Bi can yield true competitive advantage, recent technology innovations such as XML standards or direct connectivity standards such as AS2 will continue to evolve.  When XML was first announced a few years back, the common understanding what that it would replace traditional document exchange formats such as EDI.  However, as you would expect companies continue to leverage EDI and automate new business processes with XML.  Such proliferation will continue and the implication for B2Bi solutions is that they must be future-proofed to offer companies the ability to add new data or connectivity standards.
3. Trading Partner Diversity.  B2Bi projects differ from internal integration projects due to the number of parties that require cooperation in order to implement the solution.  For example, a new replenishment project that aims to reduce the stockpile or buffer inventory in the supply chain must rely on the successful cooperation of each constituent part of the supply chain – the buyer, the supplier, the freight forwarder, the shipper or the financial institution.  As supply chains continue to globalise, diversity will continue.  A B2Bi solution must therefore offer enough flexibility to ensure that all constituent parts are able to engage in the solution, maximising the potential return.  A supply chain after all, is only as good as it’s weakest link. 

These unique features of B2Bi projects must be top of mind when considering the deployment of B2Bi solutions.  To be blunt, professionals considering to implement B2Bi solutions must plan their projects for rampant diversity and limited control of external parties.  Ignoring these unique features and treating B2Bi projects like internal integration or automation projects will almost certainly deliver lower results or at the worst guarantee a failed project. 

The major benefits of implementing B2Bi within your business are discussed in more detail in the ‘Benefits of B2Bi’ section of this Microsite but in summary B2Bi can help improve speed and accuracy of business transactions, reduce costs and increase business performance.  To find out how to build B2Bi solutions, please choose the ‘Building Solutions’ button from the menu above.

A question on exploratory testing from Quora

Tester Tested !: A question on exploratory testing from Quora: How exploratory testing differs with other testing? What is the common problems faced by a tester when performing exploratory testing? .....

Exploratory Testing Techniques

Exploratory Testing Techniques

According to the speaker, here are the 4 key techniques that any testers can refer to and use for their exploratory testing.  Each component has its own strengths/weaknesses.  Tester do not have to stick with a single component, but should spread out and make use of all of them or a combination of them.  The trick is to know which one to choose and apply and when. 

1. Freestyle

This is basically Ad-hoc testing.  Hit the product from black box standpoint.  From the customer’s perspective.  Pros: Low cost.  Anyone can do it.  Encourage creativity.  Cons: May not yield the critical bugs.  Low quality bugs are typically found with lots of dupes.  Difficult to determine coverage.

2.  Scenario based

Using a pre-defined end-to-end scenarios, complete with actual reproducible steps and validation methods prior to testing.  Testers can use these scenarios as the base, and figure out new end-to-end path that will achieve the same goals.  Pros: Easy to trace the repro steps and follow.  Can determine test coverage.  Cons: Pre-defined scenarios may actually not represent what the customer really wants. 

3.  Strategy based

Testers do have some background of the product.  Thoroughly understand the architecture and flow of the product.  Tester can then leverage the product knowledge and combined with well-known testing techniques to go about testing.  More to come on the techniques later.  Pros: Test techniques are proven to be effective.  Testers just need to master them and apply them in the right situation.  Testers are also pretty much free to use their own instinct and creativity to go about testing the product.  Focus on learning.  Cons: Newer testers on the team may not have the sufficient experience or knowledge of the product to be completely effective. 

4. Feedback based

Start out pretty much same as Freestyle testing.  But as testing sessions are conducted, testers build up a history of test executions, areas covered, bugs identified, code churns, etc.  Very similar to our session notes.  Testing from historical data such as bug records, data from automations and scripts, application logs, customer reported issues, etc.  Use these data as input so tester can identify which areas may yield the most bugs.  Pros: Knowledge is not lost.  Make use of previous knowledge is very powerful.  Cons: Sometimes it’s very difficult to make use of existing data effectively (especially if there are a lot).  May actually spend more time gathering and processing these data rather than actual testing.

Network Protocol Testing Course - Introduction

Tutorial on Rally Agile Tool