As discussed in our prior articles on BRM GUI testing and BRM API testing, there are a variety of operations and modules to cover when considering testing BRM products. In this post we will discuss in detail the various components of the BRM Server and how they are tested.
The below figure showcases the different components in the BRM Server:
The BRM Server includes Connection Managers (CMs), Data Managers (DMs), and the BRM Database. The BRM Database is a major component in BRM Server, storing information about customer accounts, price lists, different service plans offered, customer payment information.
The Connection Managers (CMs) are completely responsible for communicating with the BRM server and they run the business logic software to create accounts. CMs are also responsible for data validation, for example, when a customer attempts to login to his account by entering the credentials, CM validates if the entered credentials are valid or not. The Data Managers (DMs) are responsible for converting the information received from the Client application into Database readable language, and transferring the data to the BRM database.
Using our hybrid framework, which is built using Ruby/Selenium/Cucumber scripts, we have tested account update/create, and any other action performed on a customer account.
Let’s consider the account creation example. Once a customer account is created, a new file (along with account number) is generated which is usually in XML format. The XML files are generally stored in the BRM server. By using the Net::SSH library, the XML files are accessed and parsed to retrieve the information saved in the files.
The account number is captured from the GUI and it is validated with the data retrieved from the XML file. A sample XML file is shown below.
When the account is updated with a new Serial_Number or IMEI number, another file is generated with ACTION as UpdateAccount with new device numbers ,and the numbers are validated against GUI displayed numbers. This is the same process when an account is created or updated using API calls.
The status on the customer account is also tested. This is best explained with an example where customers suspend their accounts when they travel out of country. Some customers move from one provider to another when they deactivate their accounts.
When the customer makes a call, it is recorded in CDR files. The Pipeline Manager checks the CDR files and rates each call. Rated Event (RE) loader is responsible to update the payment information of the customer account in the BRM database with the current rate.
We tested the CDR call processing using our framework. We invoked the Pipeline Manager to process the appropriate CDR files and load them in the BRM Database. Queries are run to check if the processed files are loaded into the database. Each CDR file has a transaction ID generated when processing and using the transaction IDs, and invoices are generated for each CDR file. The invoices are stored in the BRM database.
We have tested various service plans, prepaid and postpaid plans along with the pricing using our framework. Testing BRM Database is discussed in detail in our posts on BRM Database Testing.
Since all the data is managed in excel files, it is simple to maintain and update the data when needed . Whenever any new plans are added, pricing is modified, status of the accounts is changed, and the changes are quickly made in the excel files. Using our Utility files, automation scripts are automatically generated within few minutes, making the process as economical as possible.