View source | Discuss this page | Page history | Printable version   

QA Processes/Openbravo Network Testing



This document explains the procedure for testing an Openbravo Network update. On a regular basis, Openbravo Network subscribers receive notification about available packs with updates. These packs use the MPx notation (MP1, MP2, etc.)

Test process

View larger

Test begins with a current Openbravo Network installation, patched with the last update released.

From Release Management Department, an announce about a new update ready for testing will be published. Then, the Openbravo Network QA Server will have an update available.

From Openbravo Network console, go to Updates and check for updates. An update should be shown. Apply it.

Note:Backups must be properly configured for running the update.

While running the update, most of the times a compilation will be required. This is done automatically, so you can move to Logs menu to check the Compilation Log. By the interface, you can choose to see a number of lines, or you can save the log and get the complete compilation file on your local machine.

To verify update is successful:

Console testing

There are some basic testing done after every update. First, that the database backups can be manually generated. This is done by accessing Database Backups menu option and choosing Backup Now.

The other test is a rollback test. Once upgrade is completed, go to Manage Rollbacks and perform a rollback to the previous version.

GRUB 2.35MP8 - View larger

To verify rollback is successful:

DBSource Manager Testing

To verify that DBSource Manager was executed properly, the XMLs stored on src-db/database/model and src-db/database/sourcedata folder will be compared with the svn tag of the MP under testing. This is performed as a two steps test. First, just after upgrading, the XMLs will be compared with the svn tag. This is for verifying that everything was packed properly. Finally, an export of the database will be executed and the new generated XMLs will be compared against the tag as well. This is for verifying that DBSM project has done its job.

Bug Revision

All bugs fixed on the update under test will be verified.

The bug list will be verified according Defect life cycle.

Test cases

After all the steps are completed, a full set of functional test cases will be executed to assure stability.

There are two options: Smoke Test and Acceptance Test.

A Smoke Test will be the standard choice, since provide a good coverage with a reduced effort. Most of the Smoke Test is automated.

In rare cases, when some major fix is included and the risk of adding instability is high, a bigger set of test cases will be executed, the Acceptance Test. Execution effort is increased, and about 50% of the test cases will be manual executed.

Retrieved from ""

This page has been accessed 4,806 times. This page was last modified on 12 March 2009, at 17:31. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.