Talk:The QA Process

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

The original text follows. Updated to reflect move to Jira MJMcKay 17:57, 28 February 2012 (UTC)

Table of Contents{{#if: Quality Assurance and Problem Reporting Guidelines| | Quality Assurance and Problem Reporting Guidelines }}{{#if: | | [[{{{3}}}]] }}{{#if: | | [[{{{4}}}]] }}{{#if: | | [[{{{5}}}]] }} | The QA Process{{#if: Getting Involved in QA| | Getting Involved in QA }} ⇒

The Quality Assurance Process for ADempiere

The goal of Quality Assurance (QA) for ADempiere is to ensure that the released software is stable, that known bugs and limitations are identified and that the proper software development process has been followed.

Quality assurance for ADempiere involves the following:

  • A software development process that ensures changes in released software are properly controlled while allowing free development of new functionality and features
  • A governance structure that ensures the software development process is followed
  • A test strategy that ensures added functionality meets its specifications and does not harm existing functionality
  • A reporting structure (forums, trackers, wiki) that allows people to report issues and track their resolution
  • A policy of open communication where issues at all levels can be discussed and addressed

Who is Involved?

Everyone involved with ADempiere is part of the QA process and we all should endeavor to make the software better. We do this largely by being active in the project, communicating and working together. For more information on getting involved, see Getting Involved in QA.

The Issue Reporting Process

A key element of any QA process is communication - the identification of and discussion about issues. Once issues are identified, they can be triaged, discussed and solutions developed. There are three SF “documents” used in to track this communication:

  • Support Request [SR]
  • Bug Report [BR]
  • Patch Submission

All of the above documents have the following attributes.

  • Attribute
  • Description
  • Purpose
  • Status

Valid values are Open, Pending, Closed and Deleted. Pending indicates a confirmation is awaited.

Deleted indicates the document was cancelled or rejected.

  • Category

This is used to help people decide if this is a problem in an area in which they have expertise. Each Category has a related mailing list assigned. So which category selected will determine who is notified of the document via the subscribed mailing-lists, and is vital for ensuring the correct interested parties are made aware of the issue. Priority The SF priority is rated from 1 (low) to 9 (highest). This attribute takes on a special purpose with Bug reports as any value 6 and above is considered a critical Bug requiring an immediate fix and considered a “no go” for any new release. This is of great importance as it will be used to determime if any critical “no go” bugs exists in the decision to release the RC as a Stable Release.

  • Assigned

This identifies to whom the document is assigned. You can use this to assign a document to yourself to indicate to others you are working on it. This is useful to determine if the document is being worked on and by whom (or in the case of multiple people who is leading the work effort)

  • Categories

SR: Installation Problems, Implementation Problems, User Interface, Functional Problems, Customizing Problems, Extension/Programming Problems.

  • NEW AdminRequest

Bugs: Accounting, Account Schema, Activity Control, Alerts, Allocation Payment, Application Dictionary, Archive PDF, Assets, AVA (vmware images), Bank Statement, BOM & Formula, Business Partner, Calendar, Campaign, Cash, Costing, CRP, Database, Dunning, Entity (Client), Expense Report, GL Journal, Import, Installation, Inventory (Physical), Invoice, Language, Manufacturing Order, Manufacturing Resources, Manufacturing WF, Matching (PO/Inv/Receipt), Migration, MRP, Order (PO), Order (SO), Organisation, Other Functionality, Payment, Performance, Persistence, Plugins API, PostgreSQL port, Posting, Price List, Product, Product Attribute, Project, Receipt, Report Engine, Requisition, Resource, Revenue Recognition, Security, SelfService (web), Server Management, Shipment, SLA, Taxes, Translation, Trees, UI AJAX, UI HTML, UI Swing, UOM, Workflow Engine.

Patch: Widget.

Suggested All the same as :

  • Installation Problems,
  • Implementation Problems,
  • User Interface,
  • Functional Problems,

|-> Splits into

    Functional Sales
    Functional Purchasing
    Functional Inventory
    Functional Production
    Functional Projects
    Functional Finance

Customizing Problems, Extension/Programming Problems.

PERHAPS the Category in Patch is split into the svn subprojects?

Support Request

A new Support Request [SR] is created in SourceForge [SF] when a potential new bug is found and represents a request for support to confirm the bug. Before the new SR is created a search should be make to ensure the problem has not already been identified by a SR or Bug Report [BR]. New users to the project should always create SR instead of creating BRs directly, while the more experienced who are confident of a bug find should create the BR directly. To ensure people with interest in the area of this potential problem become aware and can help with confirmation and patching, the Support Request is assigned a Category. Each SR Category has an associated mailing list, and all subscribers to this will be updated with the SR creation and any updates made to it. The goal is to get confirmation of the potential bug by a second, and perhaps more experienced, project member.

  • When a SR is replied to, either in answer to the original query or requesting more information the status should be set to Pending, if no further update is made to the SR then it will automatically close after 14 Days. However, we request that people specifically acknowledge answers to their queries and Close the SR.

To ensure others are aware that “you” are working on the SR, it should be assigned to you. To be assigned a SR you need to be defined as a “Technician” for SRs.

  • If the SR is confirmed as a bug, then a new Bug Report is created, a reference to the Bug Report number is placed in the SR and the SR is Closed.
  • When creating a new SR is

Bug Report

when a Support Request [SR] is confirmed a new Bug Report is created. The list of open Bugs is what developers will use when looking for Bugs to fix. The number and priority of open Bug Reports is also how we judge the quality of a given release.


Patches are the submission of fixes for specific Bug reports. The include attached diff files that can be applied to create the new patched version of the code. Once an ERP is active many companies are adverse to upgrading outright unless there are real advances, the submission of patch files should help in the application of specific patches to a system rather than requiring the deployment of a complete new version.


  • Search the wiki for related info
  • Search the forums for related discussions - the issue may already have been identified
  • Search the current Support Requests & Bug Reports to ensure this is an unknown bug.
  • If you are unsure of the status of the issue - know bug or feature - mention it on the forums and request support from others.
  • Once you have confirmed the issue then you may proceed to create a bug tracker entry on SF.

Be sure to assign the appropriate “Category” as this will determine who is notified of the new SR.

  • Category
  • Priority

The SR will be reviewed by a peer with knowledge of this area of the application, who may answer, ask further questions or confirm as a bug. When it is confirmed as a bug a new Bug Report will be created from this SR and initial SR will be closed. As the original submitter of the SR (or even if you made additional comments on it) SF will keep you informed if there are any changes to the SR.

  • Resolution
    • Fixed
    • Invalid
    • Won't Fix
    • Later
    • Remind
    • Works For Me
    • Duplicate
    • Accepted
    • Out of Date
    • Postponed
    • Rejected

  • If you are experienced in ADempiere and are confident that you have found a new bug then you may create a new Bug Report in SourceForge (SF) directly. As with the SR submission the category selected is important as it will help others to determine if this is a problem in an area in which they have expertise.
  • As an Open Bug Report a “developer” may select this assign themselves to the bug to ensure that others will not work on the bug at the same time. If you wish to collaborate you can contact the assigned developer via SF.
  • This is a process based on “Peer Review”
    • is the change for a specific bug?
    • does the code fix the problem?
    • are the coding standards adhered to?

See Also