Telecom Billing System Test Cases

Test Case For Telecom Billing System Test Case

This post is based on a request from a reader regarding the test cases for the telephone billing system asked in the interview. Considering the telecom companies in the IT sector, this post will help freshers to get an understanding of how to write test cases for such an application. 

What is Telecommunications?

The telecom billing system is quite complex, and each telecom operator maintains a different system for customer records. I had a chance to check out Vodafone and BSNL billing system, I have observed the workflow of the software used. So using that workflow, I am going to write some of the sample test cases for the billing system.

Customer service centers have three different modes of payment systems – Self-service kiosk, Cash transaction on a counter, and card transaction. Each of these payment methods will change the structure of the billing system. For the sake of simplicity, let’s assume we are using the cash transaction on the service counter.

Here a customer service staff member will take a phone number and bill amount from you. He/She will add your number to the billing system and generate customer records. This record system has an option to see the current bill, past paid and unpaid bills, mode of previous transactions (cash or card), late fee checkbox, service request option, and statements. It also generates the print after the successful payment from the client. The billing system then updates the core server to change the bill status from unpaid to paid.

Check out this old billing system that was in use prior to GUI based software. Due to the simplicity in the old systems, there was less room for error when it comes to choosing the menu options. However, the errors were introduced as there were no input validations offered by external libraries to developers.

Test Cases for the Telecom Billing System of a Telecom Operator

• Check the telephone number of the customer and see if it exists as a current customer under the telecom operator.
• Check if the number is working or not.
• Check if the number entered is a valid 10 digit number.
• Check if the number is not blocked due to reasons.
• Check if the number has an active billing cycle.
• Check if the number has unpaid billing history if it exists, shown on screen.
• Check if the number’s previous billing amount is paid.
• Check if the system allows statement generation as per customer requirements.
• Check if the system has recorded a number of calls accurately.
• Check if the plan selected by the customer reflects in the billing system.
• Check if the plan upgraded is selected by customer data in the system.
• Check if the plan downgraded is selected by is the billing system.
• Check if the value-added services are enabled or disabled.
• Check if the total amount is accurate and mapped to the services offered.
• Check if the tariff plan is properly calculated for the billing cycle.
• Check if the number of calls is valid by matching them to customer records.
• Check if the prepay system has accepted additional money for future billing.
• Verify if the prepay balance is used in the current billing.
• Verify if the floating-point balance is carried forward into the next bill.
• Verify if the customer pays the bill, and it reflects in the system.
• Verify if the customer has chosen a card or cash transaction.
• Verify if the card transaction has been successful in the payment terminal.

These are some of the common test cases regardless of the telecom operator. The test cases will increase once you get your hands on the system workflow of the respective telecom billing system. The option for a service kiosk and card payment will increase the number of test cases that you need to cover. Each field will have its validation check. Depending on whether it is a web-based or VB based application, you’ll find the validation checks different in each application.

Now you can format your test case document by using these fields – test case id, description, test data, expected result, actual result, pass or fail remark, bug description. This should help you form a test case document for verifying the manual testing defects in the application.

I hope you have found this post useful for your manual testing practices. Feel free to let me know if you find these posts helpful. I’ll help you with more test cases in the future.