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

Bug Reporting Guidelines

This article is protected against manual editing because it is automatically generated from Openbravo meta-data. Learn more about writing and translating such documents.

Contents

Introduction

If you have found a defect or you want to request a feature enhancement an issue report is the way to bring the attention to the Openbravo Community.

The Openbravo Issue tracker is the database of defects and feature requests for the Openbravo projects. It helps developers keep track of issues and who is fixing them. Users can join Openbravo effort by making their bug reports clear and specific. The better the issue is reported, the easier it is to identify the cause, and fix it.

The Issue Life Cycle

Before you start working with issues, it is important that you have a good understanding of the issue management process at Openbravo, which is represented in the following diagram using the BPMN notation.


IssueFlow-BPMN.png


There are four actors involved in this process:

The progression along this process is tracked using the issue status, which can evolve according to the following status transition diagram.


IssueStatuses.png

Issue Classification

Openbravo uses two classifications for issues:

  1. Issue Type
  2. Project

Issue Type

Issue Type classifies whether an issue is a:

We are aware that distinguishing among defects, design defects and feature requests often is not an easy task and that there are a number of situations where this is not a clear cut choice: sometimes the intended behaviour is not clear or, worse, the product might work as specified but the specification might not meet the users' requirements. That said, we believe that this is an important distinction as every type should be handled differently. In particular, defects should be resolved at the earliest opportunity while design defects and feature requests require planning, design and therefore need to be explicitly scheduled for a given release. Also, design defects should address any potential void in the functional requirements while feature requests should focus on functionality that does not exist yet or it is not complete.

Projects

Projects are the highest level of containers for issues and an issue must belong to one and only one project.

Projects determine who is responsible for resolving the issue and what attributes must be captured during the issue life cycle. Additionally, summary level statistics, road maps and change logs are all maintained at project level.

Openbravo uses the following projects:

How to Report an Issue

This section contains a step by step guide and some good recommendations on how to properly report issues.

Warn-icon.png   Important Note: Remember issues.openbravo.com is a public website. In order to fulfill the GDPR please do not expose any information related to the customer in the ticket.

Before reporting a bug

Please, before reporting a new bug, make sure that:

Quick guide to writing good bug reports

Software problems are sometimes complex issues. Writing a good issue report makes it easier for everyone (developers, testers, ...) to understand the problem and find a solution.

Based on Mozilla and Simon Tatham bug writing guidelines, a good bug report always...

Step by step issue reporting guide

View larger
  1. Are you sure that you are going to report a valid issue?
  2. If yes, navigate to https://issues.openbravo.com.
  3. Before you can report your issue, you need to login. If you do not have an existing username, you can signup for a new account.
  4. Start reporting your issue by clicking on Report Issue link at the top of the screen. You will be taken to the screen below.
  5. Make sure that you have chosen the right project on the top right of the screen. For example, if you want to report an issue about Openbravo ERP, make sure that Openbravo ERP is selected in the drop down list.
  6. You are now ready to start logging your issue by specifying the following attributes:
    1. Project
    2. Type
    3. Category
    4. Severity
    5. Reproducibility
    6. Priority
    7. Profile
    8. Product Version
    9. SCM revision
    10. Modules
    11. OBNetwork customer
    12. Assign To
    13. Target Version
    14. Summary
    15. Description
    16. Steps To Reproduce
    17. Proposed Solution
    18. Upload File

Project

In case you just realized that you have entered into the wrong project and want to go to other project, then just change this option to the correct project.

Type

Issue types are:

Category

This classifies the issues by area of impact. The list of categories depends on the project. Choose the category that you feel it is most representative of your issue.

Severity

Use this attribute to assess of the impact of this issue to the end user. The following values are possible:

Bulbgraph.png   See How to Choose the Right Severity section for more details.

Reproducibility

Use this field to specify the degree of reproducibility of the issue:

Priority

Expresses the order in which issues should be addressed by the resolving team.

Always use Normal priority when reporting an issue. This Normal priority is then altered based on:

While severity is assessed by the defect reporter and contributes to the assessment of the priority, it is only one of the contributing factors and, in the end, priority is assessed by the development team and reporters cannot change it.

For more information about how the Priority is set, check the page about determining the priority

Profile

Use this section to describe your environment:

You can select either a pre-defined profile or specify individual values.

Bulbgraph.png   While this section is optional, it is important to specify your environment configuration especially if you are reporting a defect that you suspect might be platform dependent.

Product Version

Choose the version of the Openbravo product you are experiencing a defect with. If you are using Openbravo ERP Developer's Edition building from sources out of source control, please select pi.

Bulbgraph.png   This field is optional but you should populate it when reporting a defect.

SCM revision

If you are reporting a defect on pi, please specify the revision or changeset you are using.

Modules

This contains a list of modules related to 3.0.

OBNetwork customer

Indicates whether the issue is reported by an Openbravo Professional Subscription Customer.

Bulbgraph.png   To be ticked only by Openbravo Professional Subscription Customers.


Assign To

Developer that will be assigned the issue.

Bulbgraph.png   Unless you want to assign this issue to you, leave this field blank.

Target Version

Expected resolution version for the issue.

Bulbgraph.png   To be completed only by Openbravo Professional Subscription Customers.

Summary

A clear abstract of the issue. Summaries like Program hangs or It doesn't work are bad samples of a title because they do not provide any indication of where or how the program fails.

Description

A detailed description of the issue. The error log pasted or attached helps a lot.

Steps To Reproduce

In case of defects, please provide detailed reproduction steps. Use numbering for a better understanding:

  1. Step 1
  2. Step 2
  3. Step 3
  4. ...

You can also record the steps that you follow and attach or paste a link to the video.

Proposed Solution

Optionally, you can suggest a solution to the problem.

Upload File

You can use this field to attach to your issue error log file, screen shots or any other file you think might clarify your report.

How to Choose the Right Severity

The Severity attribute of an issue expresses the impact that the issue has on end user. It is different than Priority, which expresses the order in which issues should be addressed by the resolving team, but it is one of the factors that drive priority.

Severity is expressed by the reporter while Priority is controlled by the resolving team. While Severity is assessed by the defect reporter and contributes to the assessment of the Priority, it is only one of the contributing factors and, in the end, priority is assessed by the development team and reporters cannot change it.

Following list consist of some questions that may allow you to decide yourself the measure of severity.

The number of Yes on the previous questions should give you a good idea about the severity.

Some examples about severities can be found in the following list. Please have in mind that the list is not definitive, since other factors as the above conditions may increase or decrease what is marked following this table.

For example, "Page title missing" is listed as minor. But if it only happens under some circumstances, or only to some specific role, or on a specific browser version, the severity should be set as trivial.

For more information refer to How to determine the Severity.

Issue Type

Severity Level
Defect Feature Request
Critical

Results in the failure of the complete software system, of a critical subsystem so that no work or testing can be carried out after the occurrence of the defect. It also applies to data loss failures and with processes that leave inconsistent data stored on the database.

  • Login does not work.
  • Main page does not load.
  • A null pointer exception on a critical subsystem.
  • It is not possible to use the system on some of the most common flows.
  • Performance Issues (If specified by a Customer).
  • Do not use this severity for feature requests.
Major

Causes failure of entire or part of system, but there are some processing alternatives which allows further operation of the system. It also applies to the system crashing, or aborting, during normal operation of a non-critical flow.

  • Functionality missed out / Incorrect implementation (major deviation from Requirements).
  • Performance Issues (if not specified by a Customer).
  • Mandatory field validation is missing (allows wrong data generation)
  • Screen layouts issues (which hinders functionality)
  • Browser/OS incompatibility issues (for widely used combinations).
  • New functionality that would significantly increase the user base of the product.
  • Usability improvements.
Minor

Do not result in failure but causes the system to show incorrect, incomplete, or inconsistent results (note that show inconsistent results is way different of generating inconsistent results at database level as explained above). A critical usability issue fits also in this category, as well as if there is a simple workaround.

  • Functionality incorrectly implemented (minor deviation from Requirements).
  • Screen layout issues (do not interfere with the system but are notorious)
  • Keyboard shortcuts not working
  • Field validation is missing (does not allow wrong data generation)
  • Page titles missing.
  • Pages style different than Front End / Main Page style.
  • Default Value missing for the fields required.
  • Missing images or text which does not hinders functionality.
  • Browser/OS incompatibility issues (for supported but not widely used combinations).
  • Documentation errors
  • New feature or revision of existing feature that would significantly improve the usefulness of the product.
  • New feature that would improve the internal qualities of the product.
Trivial

Small errors that do not prevent or hinder functionality, typos, grammar mistakes, wrong terminology, general usability issues and styling.

  • Generic screen layout issues
  • Cursor Set Focus and Tab flow on the Page.
  • Spelling Mistakes / Grammatical Mistakes.
  • Alt Text for Images.
  • GUI image colors etc.
  • New feature or revision of existing feature that would marginally improve the usefulness of the product.

Proposing a bug fix

If you are a software developer and you have found a solution for the problem that you are reporting, you also can help Openbravo providing a fix for the problem and attaching your solution to the bug report. You can use the hg export or expose your repository in a public location. Before submitting the patch, remember:

Resolving an issue

As a general rule defects should be solved by triggering actions from the Mercurial commits. For more information follow the Mercurial and Mantis integration user instructions.

If you can not resolve an issue by triggering an action from the Mercurial commits, just change issue status to Resolved, linking to the push done.

Rejecting an issue

If the issue has been rejected, you must indicate the reason why it has been rejected. For instance, the issue could be:

Rejected issues change their status automatically to Closed.

Sample Openbravo bug report

This is a sample bug report. Notice that it follows all of the indications that we have just described:

Environment

Provides Openbravo ERP, database, operating system, JDK, Tomcat and Ant versions.

Category

[Openbravo ERP] 08. Project and service management

Summary

ExpenseSOrder and RequisitionToOrder processes fail in PostgreSQL

Description

ExpenseSOrder and RequisitionToOrder processes fail in PostgreSQL because in their XSQL, date passed to M_GET_OFFERS_PRICE function do not have a to_date().

Steps to Reproduce:

  1. Create an Expense Sheet.
  2. Create an Expense Sheet Line (with Reinvoicing ticked) and select a Business Partner
  3. Go back to Expense Sheet header and process this expense.
  4. Create Sales Order from Expenses for the Business Partner.
In the log, message 'ERROR: function m_get_offers_price(timestamp with time zone, numeric, numeric, numeric, numeric, numeric) does not exist' displays.


Bug-Sample.png


Disclaimer

Please NOTE that this is a Community Edition tool without any warranty to resolve issues. If you want to have predictable SLA you need to register tickets through Support Portal which is for Professional Edition only. For more on how to get/acquire Professional Edition please read this.

Retrieved from "http://wiki.openbravo.com/wiki/Bug_Reporting_Guidelines"

This page has been accessed 144,997 times. This page was last modified on 30 March 2023, at 06:57. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.