Revenue Management is a major component in any business, and especially so for customer centric B2C industries, such as telecommunications. BRM (Business Revenue Management) systems can be used to manage the complete flow of revenue information. 3Qi has been involved in testing BRM components by leveraging our in-house product, Awetest. Awetest is a cloud-based testing tool which supports cross-browser testing using frameworks built on various modern technologies.

Let us dive into the BRM Revenue Management Lifecycle to understand the various modules involved. BRM is a large deployment for any company and hence only specific modules are leveraged. Modules are added or excluded and modified depending on the organization’s requirements.

BRM Revenue Management Lifecycle 

12412421Capture

Revenue Generation: This aspect constitutes the services (including the customer service and the product plans) offered to the customers and the pricing related to the services rendered. The purpose of this aspect is to help the customer connect with the right offering at the right price, in addition to helping resolve any discrepancies in payment as well

 

BRM_O_2

Revenue Capture: The entire process of revenue capture is described in the figure below:

BRM_O_3

To understand the revenue capture process, let’s consider a basic example of making voice calls. When you make a call through your phone, your account is first authorized by validating your phone number with any account that was associated with prior customer records. Since your phone number is attached to your registered account, all the call related data, i.e, the number of minutes you were on the voice call, start time and end time of the call, time of the day, date and month is recorded in CDR (Call Detail Records). The pipeline manager is responsible for checking the plan you are currently utilizing and the rate for the voice call. The data is stored in the BRM database by the RE (Rated Event) loader, which also updates your account with the new bill. 

The revenue capture process is invoked when an event (in BRM terminology) occurs i.e, when you make a call or access the internet.

Revenue Collection: Any payment related processes are involved in revenue collection.

BRM_O_4

Invoice is created at the end of every billing cycle and updated in the customer account. Revenue collection also includes all the different payment methods such as Credit Card, Debit Card, Checks. If you setup automatic payment cycle, the amount is deducted from the desired payment account and it is recorded in the BRM database accordingly.

Revenue Analysis: A detailed report on all the activities on a customer’s account which could be call related, internet, etc., is developed and analyzed for future reference, or can be used to devise new plans/modify existing plans.

Given that we now have a basic understanding of the BRM lifecycle, we can focus on the complex testing that occurs within the BRM lifecycle.

Testing Approach for Oracle BRM 

For our customers, we conducted end-to-end testing of their BRM instances by leveraging Awetest and the different automation frameworks we’ve developed over the years.  We will be writing a series of posts that will detail out our approach to automate BRM testing, primarily centered around the four core testing scenarios which occur in BRM: 
BRM_O_6

BRM GUI Testing: Revenue Generation is a part of GUI testing since it contains the UI interface where customers can access their accounts. The goal here is to test the functionalities of the UI accessed by the customers, as well as the customer representatives.

API Testing: Some of the actions on the customer accounts must be done in the backend. This is used extensively when customers try to update something in their account. This is when service calls are greatly helpful, by completing the function and also updating in the BRM database.

BRM Server Component Testing: Validating if all the components in the BRM system are functioning as required. This includes creating the customer accounts, updating and deleting them. Also verifying if any XML confirmation files are generated whenever an action is performed and the data in the files is validated.

BRM Database Testing: BRM Database is a major component in the BRM system where all of the customer information is stored and maintained. All of the data going in and coming out of the database must be monitored, categorized, and validated at every step.

Using our hybrid framework which is facilitated in 3-ways i.e, Web Browser, Service API and Database connections, we can test the BRM system. The test data is maintained and managed in Microsoft Excel files and so the tests were easily updated whenever there is a change in the BRM system. Stay tuned for our upcoming posts that will delve into how we approach automating BRM testing.