Bug Closing Guidelines

Contents 1 Introduction 2 Process of closing issues 3 Issues to verify 4 When and who closes issues 5 Verifications to be done to close an issue 5.1 The issue report 5.2 The code that fixes the issue 5.3 The functional behavior

Introduction

The process of checking a resolved issue as closed is the verification that the issue has been properly fixed and it is ready to be published.

This process has the following objectives:

• It does not introduce any regression issue.
• The issue has been fixed and the application does not fail when following the steps described in the issue report.
• The changeset associated with the fix has good quality. Is the most simple solution possible and it follows the development guidelines.
• The changesets that fixes the issue are atomic and complete. Do not do any other thing than fixing the issue. It does not change any other behavior apart from the error described in issue report.

Process of closing issues

To verify and close issues is one of the required steps of the Openbravo ERP release process. As a general overview the process is:

1. RM freezes the repository and notifies the mailing list about it. Following the usual logic: all the commits done up to the 15th go in. And the freeze is done the 18th.
2. After Support finishes the verification of all issues included they notify the mailing list about it. Also the release notes needs to be updated adding the most relevant issues fixed since the latest version.
3. QA starts the update tests.
4. If they are successful QA gives the greelight in the mailing list and RM publishes the release.

Issues to verify

The issues that needs to be verified are all the issues resolved that will be included in the new release that is about to be published. In other words, all the issues that have a related changeset in the changelog of the repository that is going to be used for the new release since the previous release must be verified.

To help in this task the reports published in https://issues.openbravo.com/changelog.html include all the issues with a related changeset since the previous release. For example, in the report bellow the header Defects in Core are listed all the issues that have to be verified.

When and who closes issues

Issues must be closed as soon as possible they are resolved. All resolved issues go to the backlog of pending issues to closes. Before publishing a new version all issue fixes that go in that version must be verified and closed.

The person who closes the issue must be a person with experience in the area related to the issue and in the best case must be the person who reported the issue because this person has already experience in the issue reported and in most cases knows all the cases related to the issue apart what is explained in the issue report and also may already have an enviroment to test the issue.

For OBNetwork issues the support member that reported the issue will be the most accurate person to close the issue. For other issues it can be asked to the reporter to close the issue if available or if not possible, any member of the support team with experience o in the functional area related to the fix.

Verifications to be done to close an issue

From the issue report perspective the only change needed to do is to modify the status of the issue from "Resolved" to "Closed". But this status change involves that the following verifications have to be done by the person responsible:

The issue report

First the issue report needs to be properly resolved:

• The issue report is in status "Resolved"
• The field "Fixed in SCM revision" includes the URL of the latest changeset related to this issue.
• There are in the notes one or several entries automatically generated by the hgbot process with a summary of the changeset related to the issue or that fixes the issue. A changeset related with an issue is a changeset that has in the comment a sentence like "Issue XXXXX" and fixes the issue if the comment is like "Fixes issue XXXXX", where XXXXX is the issue number. An example of this kind of notes is the following: https://issues.openbravo.com/view.php?id=15483#c34474
• The commit comment of the related changesets written by the developer explains properly all the modifications included in the changeset.
• There is a note explaining the steps to test the issue and the areas affected. This note must explain how to verify that the issue has been fixed, the behaviour modified and areas that may be affected by the fix. An example of this is the following note: https://issues.openbravo.com/view.php?id=16045#c34495

If the issue is not properly resolved the person in charge of closing the issue must ask the developer who resolved it to complete properly the issue resolution.

In the particular case of platform issues, it will be necesary to contact the person who fixed the issue or any other member of the platform team to understand properly what the issue is and how to test it properly.

The code that fixes the issue

After it has been checked that the issue report is properly resolved it has to be verified the correctness of the changeset that fixes the issue. To perform this task it will be helpful the diff of the changeset with all files and lines modified of the source code and the developer commit comment.

The aspects of the code that fixes the issue that must be verified are:

• The code is clean. Formatted according the Openbravo guide lines and with accurate comments.
• The changesets are atomic and does only what is explained in the commit comment. For example one changeset must not include the fix of two unrelated issues, each fix (if possible) must go in its own changeset.
• Every changeset is complete, there are no partial changesets. For example one changeset must not include references to other classes that will be included in a later changeset.

The functional behavior

Once the issue report and the code has been reviewed is the time to check that the issue is actually fixed. To do this it can be used the Openbravo ERP application deployed in the live builds servers: http://live.builds.openbravo.com or a local instance built from the sources using the repository where the fix has been published. To execute properly the functional behavior verification it is helpful the developer notes "How to test the issue" and "Other areas affected".

The functionality and behavior that needs to be verified is:

• The issue has been fixed and the application does not fail when following the steps described in the issue report.
• The same issue in other parts of the application is fixed too. It has to be verified all the cases that are the same as reported in the issue are fixed too. For example if the issue fixed is related to the Sales dimensional report it has to be verified too that in the rest of all dimensional reports of the application the issue is fixed too or does not apply.
• It does not introduce any regression issue. This is the the most important point of the functional verification. A regresion is a defect introduced by a changeset related to a behavior that from the user perspetive it worked properly in a previous version. This is the worst case at all becouse it means that a new changeset in the sources repository is introducing a new defect. If a regresion is detected an action has to be taken immediately. First notifying it to the responsibles of the product and second, if a safe fix for the regresion cannot be applied in a matter of few hours, the changeset that introduced the regression must be backed out (hg backout) immediately. Have a look to the document ERP/2.50/Developers_Guide/Best_Practices/Rules_for_avoiding_Regressions that explains from the developer perspective the best practices to follow to avoid regressions. In general, these are the verifications that have to be done in order to avoid regressions:
  • It still works the general case. For example if the issue fixed was reproduced when voiding an invoice with discounts, and in a currency different to euros. It has to be verified that invoices without discounts in euros can be voided too.
  • It still works other functional flows that use the same functionality. For example if it has been fixed an error when deleting an error modifying an SQL trigger it must be verified that the application still works when inserting and updating records related to the SQL trigger modified.
  • It still works in other environments. For example if it has been modified a complex report SQL sentence or a complex PL/SQL procedure, it must be tested both supported database engines. Or for example, if it has been modified a complex behavior in a manual HTML window, It must be tested all supported web browsers: Internet Explorer, Firefox...
  • Fixes in core flows fixes must require a planned and deeper testing. This applies for example to the PL/SQL procedures that processes invoices, orders, shipments; the accounting engine, etc. To perform this task it is helpful the report changelog, that includes a list of all the files that has been modified since the last version.