Working with Mercury Quality Center

Last few weeks I’ve worked with Mercury Quality Center (MQC). This product can be used to register the test scenario’s you made. For example the functional tests in Oracle E-business Suite. In MQC the scenario’s can be registered so tests in the future can be done in the same way as you did the original test. A very nice feature of MQC is that the tests can be automated. When the tests are automated the time you need to test your system can be reduced by hours. For example you can activate the test when your leave and when you come back the next morning the test results are displayed.

In this article I will give you a brief introduction to the possibilities of MQC.

Personally I used MQC to register test plans for the module Oracle Incentive Compensation (OIC), which is a part of Oracle E-Business Suite.

In MQC there are five modules. In each module you can register different data. The data that is used in a higher module (as you see it in screenshot 1) can be used as input for the module that is displayed under it. For example the data registered in Business Components can be used as input for your test plans. I advise to do it this way. It reduces the input that you have to make and it gives you the possibility to re-use the input you already made.

Screenshot 1: The modules

For building Business Components I had been advised to use a view on your screen as starting point. Most of the business components I made exist of one view on the screen indeed. Sometimes I had to use more than one screen as input, because the process I was describing has a few follow-up screens. For example collecting transactions in OIC can be done in one screen, but calculating the compensation amounts uses four screens.

In the Business Components you register all the fields that have to be filled with an input parameter and you describe every step that you execute. This can be filling in a field with a parameter or pressing the “ok” button.

Screenshot 2: parameters

The activities that have to be done for Business Components are:

• Deciding which input parameters will be used.
• Decide whether there’s an output parameter.
• Registering the different steps that have to be performed.

Screenshot 3: Design steps

After building the Business Components I made Test Plans. The Test Plans exist of multiple Business Components. In a Test Plan I use for example a Business Component for starting Internet Explorer, a Business Component to sign-in in Oracle EBS, a Business Component for the part of the module I want to test and a Business Component to sign-out and close Internet Explorer. Every Business Component can be automated of its own. If all the Business Components in a Test Plan are automated, the test is also automated ( How predictable!!! ).

Sometimes you want that a Business Component is placed more than one time in your test plan. If the Components must be done after each other (without a different Component between it) you can use iterations. This means that the Business Component is placed just once in the test plan and that the Business Component will be executed as many times as there are iterations. Every iteration can have a different value as input for the parameter.

In OIC I made the decision to control my tests for three salespersons, therefore I used iterations to request a report three times. The output of these request will be automatically be saved in the attachment section in MQC. When I open the output I can control for every single salesperson the test results.

The steps that have to be done to make Test Plans are:

• Decide which Business Components are necessarily to execute the Test without missing a step.
• Describing which input files will be used and when they will be used.
• Set the right values for the input parameters.

Screenshot 4: Test plan

When you make test plans you can execute only one test at a time. To do a total test of the system you should make a very sizable Test Plan, but there’s a much easier solution. In Test Lab you can put different Test Plans after each other. This has two advantages. 1) You can make the Test Plans specified to one single process and 2) you can easily run different Test Plans after each other.

In Test Lab you can also activate the test. You can choose between an automatic run (all business components must be automated) or manually. If you run the test manually you see all the different steps you have to make. So you can review the business components you made and make sure that they’re complete and the description of the different steps is clear enough.

For making the Test Lab complete you must do the following actions:

• Decide which test plans make your test complete, and put them in the right order.
• Control whether your test plans are complete and the describing is enough specified.

When the test run is completed MQC shows the result. For example: passed (that is what you hope and expect). If the test fails you can describe the reason for failure in the Defects section. If you execute the test multiple times all the results are saved. So you can see when the test failed and passed. This makes it possible to see what changes affect the system.

Bottleneck

During the project I made really quickly all the business components I needed. So I thought that I was almost done with the project. But the most difficult part was not even started. After creating the business components, I had to think about the right order to place the different components after each other. For every test I made, I had to use the same time that I had used to create all the business components together. After that I was just halfway the project, I experienced!

When the tests were right, I was thinking in which way I could make the outcome predictable. I decided to use input files. These input files had to be the same every time you redo the test. To achieve this I had to make clear that the filename must change every time you do the test. The files must be placed in the right directory also.

Making clear in MQC and for myself which files must be used, with which name and in what directory to place, took most of time I spend for this project. But after that … the project was finished!

Screenshot 5: Test lab

Conclusion

I think MQC can be a very strong tool for functional tests in ERP-systems like Oracle EBS. But it is important to make the business components reusable and make sure that everybody uses the same terminology (for example: use <B> instead of the description: press the button). If both are done, your test results can be achieved quicker and test are always done in the same way. When the tests are completely automated you will have the test outcomes much easier (just activate the test) and quicker. The test will be running while you can do other work (or take a quick nap).

Secondly you must make sure that you can predict the outcomes of your tests. So you can decide: did the test failed or passed. To achieve this you must ensure yourself of using the right input files.

For me the project I did with MQC was successful. Being only 23 years old, I could use the experience of working for a customer.

For more information about OIC, lookup the BLOG my colleague Richard de Boer made.