QA Processes/Openbravo Network Testing

Introduction

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.

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:

• Openbravo Console shows the proper version number
• Openbravo ERP's about box shows the proper version number
• GRUB initial menu shows the proper version number
• The database, on the ad_system table has the proper version number

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:

• Openbravo Console shows the previous version number
• Openbravo ERP's about box shows the previous version number
• GRUB initial menu shows the proper previous number. See sample image with 2.35MP8.
• The database, on the ad_system_info table has the previous version number
  • Please note that prior 2.40 the table containing the version number is ad_system
• Choose two bugs of the list of fixes for the new release and verify they can be reproduced.

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.