QA Processes/Defect life cycle
Defects are a difference between expected and actual behavior of the software. QA team main task is to implement methodologies to minimize defect creation trough the whole development process and to manage found defects to ensure proper fixing. Once found, each defect has a life cycle, starting when is reported and ending when is closed.
Complete defect life cycle
A defect is created when found, either by a community member, QA or anyone using or testing the system. After a triage, the defect is scheduled, fixed and verified.
QA verification process
Within the above life cycle, QA process has a two stage verification process. First, on a regular basis, defects are verified on the SVN development branch. And after a release is packed, a selected subset of bugs, mainly critical ones, will be tested again.
On a weekly basis, all defects on Resolved status will be verified.
By using Mantis filters, the list of defects on Resolved status will be obtained. This list includes both defects and backports.
Definition: On Openbravo Issue Tracker, a Defect is a reported issue. By default, it applies to trunk.
Definition: On Openbravo Issue Tracker, a Backport is an issue created by triage. There is a backport for every active branch where that issue applies. The backport policy is defined in Backport Management.
Installing/Updating Openbravo branches
Having the list to verify, is necessary to get the last SVN version of every branch. This should be performed by a SVN checkout if it's the first time:
On Windows: Using a SVN client, like Tortoise, select a folder and execute SVN Checkout command from context menu.
On Linux: Execute the checkout command:
svn co <branch_path> <destination_folder>
To configure Openbravo, see <TBC>. After that, execute an installation:
If a previous version of the SVN branch already exist, just an update is necessary. And update the database:
Verifying the branches
For each defect of the list, it should be verified against the corresponding branch. The defect could be properly fixed, then the issue is closed (changing status to Closed), filling the Tested In Version field. Or the defect could be still reproduced, then the defect is reopened (changing status to New). Is very important to add as many new data as possible in order to let the developer understand what was not properly fixed.
Marking as Regression
After all the defects were verified, some of Closed defects will be marked as Regression. This will be done mainly for Critical defects, and/or for any defect that is considered relevant.
QA on releases
When a version is packed in a release candidate installer, all defects marked as regression for the source branch. A release can be, for example:
- An alpha version
- A beta version
- A production version
- A maintenance pack
The defects to be verified will be obtained by filtering the defect list by corresponding release and those with the Regression mark.
Installing the release
The release will be installed from BitRock installer.
Verifying the branches
For each defect of the list, it should be verified against the release. The defect could be properly fixed, then the Tested In Version field is changed. Or the defect could be still reproduced, then the defect is reopened (changing status to New). Is very important to add as many new data as possible in order to let the developer to understand what was not properly fixed. It's also important to verify what happened between branch verification and release packing.