QAProcess
From AdempiereWiki
Contents |
Adempiere 3.1.5 Release Candidate 1 (RC1)
If we take ourselves back to September, when we forked from Compiere, the goal was to create a project that did what Compiere Inc did not!
- To raise the quality of the product enough to allow it to be used in a production without first spending 6 months bug fixing.
- To complete and polish the functionality that existed in the application before introducing new functionality for the sake of it.
With the release of 3.1.5 [or RC1] this task begins in earnest.
Release Strategy
The Release Strategy is defined and controlled by the Commit Committee.
This strategy calls for a multi-staged release with Release Candidate [RC] versions numbered uneven and stable production releases number evenly.
So for example the Development is equivalent to the SVN trunk and is in constant flux, as developers commit code. When the core development for a given release is completed the trunk is frozen with the creation of a new branch, in which testing and bug fixing may be applied while the major core development of the following release can continue in the trunk.
Any binary release is “tagged” to enable the precise source code used in the creation of any binary release to be derived.
In a perfect world the trunk will be frozen as Release Candidate 1 (RC1), against which all future bug fixes are applied. When all known critcal bugs are addressed the RC1 is tagged as the stable version. The binary release of this version will be created from this tagged version. If unplanned core functionality changes are included in the RC1 then it can be tagged RC2 to indicate a major core change occured.
All patches applied to the RC to create the Stable version must be merged into the trunk (which now represents the next major release), to ensure fixes made in one version are included in the next release.
The road to our first Stable Release has taken an at ypical route with the actual releases as
So we stand now at v3.1.2, ready to begin the task of Quality Assuring the Release Candidate to create the Stable Release.
Why do we need a QA Process?
The Adempiere bazaar is a fast moving dynamic environment, but in order to Assure potential users of the Quality we need to, at a minimum, indicate what functionality has been tested and in which environments.
What is the goal?
The technical goal is apply all submitted patches and to remove all critical bugs and as many non-critical bugs as possible from the Adempiere Release Candidate to create the Stable 3.2 release. But for a truly complete release we also need to ensure:
- a) a quality product,
- b) a quality installation process,
- c) quality documentation.
Who is Involved?
Three basic roles have been identified within the project:
and anyone can play each and/OR all of these roles.
Appropriate Tasks
- New Users to the project
- test the install, provide feedback on aspects that did not work as expected or are unclear on,
- read the wiki documentation and submit document enhancements,
- add new documents containing your expert knowledge on specific domains.
- Experienced Users
- test the application functionality,
- review SF Support Requests to determine if new bugs are reported,
- confirm SF Bugs and writing up test scenarios for the developers to work with in the creation of fixes,
- test submitted SF Patches to confirm bug fixes.
- Developers
- check out the SF Support Requests & Bugs sections for a list for possible & confirmed problems (this is a great way to learn the application!),
- submit SF Patches for report bugs.
- Commiters
- review SF Patches submitted to test, confirm & commit,
- submit new SF Patches to confirmed SF Bugs,
- review & confirm new SF Bug reports,
- review SF Support Requests to confirm as bugs.
QA Process Overview
The application documentation is maintained from within the wiki. Once you have registered you may edit the wiki. Any changes made are reviewed and confirmed via an informal process of peer review. Within the QA process of the application itself, however, a more formalised process is followed. This is because, unlike the deveolopment process, many (perhaps even most) people will be working with a binary release. So we need to keep a detailed account of what was changed and why in any given binary release. There are three Source Forge “documents” used in the QA Process:
- 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.
Patch
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 requireing the deployment of a complete new version.
Process
The following illustration gives an overview of the QA Process.
Determining a Stable Release
So you think you found a new bug – what now?
- First search the current Support Requests & Bug Reports to ensure this is an unknown bug.
- Once you have confirmed this then you may proceed.
- Okay, well if you are new to the project then the best approach to take it create a SourceForge Support Request (SR).
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
https://sourceforge.net/docman/display_doc.php?docid=24202&group_id=1#issue_status
- 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
- Quality Control Cycle checklist by Victor Perez
- Getting Started on QA by Colin Rooney
- Contributors Needed- Sign Up Here
