QAStart th

From ADempiere
Revision as of 05:03, 3 June 2010 by Kittiu (Talk)

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

ใครเข้ามาช่วยได้บ้าง

คำตอบง่ายๆก็คือทุกคน!

The QA Process is concerned with ensuring the stable releases have:

a) a quality installation process,
b) a quality application,
c) and quality documentation.

If you are a new user

  • then 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.

If you are an experienced user

  • test detailed application functionality. There is not defined test plan and you may be testing something someone else is also testing, but we all work in different technical & business environments so it is not wasted time. All that can be required of you is to confirm it works as you expect it in your environment.
  • review SF Support Requests to determine if new bugs are reported. Do assign yourself to the Support Request to let others know you are working on this issue. If someone has already been assigned you can contact them via their SF email address to see if you can help in anyway.
  • confirm SF Bugs and writing up test scenarios for the developers to work with in the creation of fixes,

If you are a new developer

  • check the SF Support Requests & Bugs sections for a list for possible & confirmed problems (this is a great way to learn the application!),
  • if you intend to work on a bug assign the bug to yourself to let others know that you are working on this problem. If there is already a name assigned you can contact them via their SF email address to see if you can help.
  • submit SF Patches for report bugs.
  • test submitted SF Patches to confirm bug fixes.

If you are a commiter

  • 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.
  • Be clear with the Log Message when you commit, a good practice could be:
[bug #] - Description (example: [bug#1618305] - Password reset to defaults)
or
[SR #] - Description,
and so others can easily find the details behind the commit.

How do I start?

The software QA processes is managed from within SourceForge (SF) so, if you do not already have one, register with SF to get an SF user-id.

If you wish to make updates and enhancements to the wiki, then simply register on the wiki. Do tell us something about yourself and your testing environment(s) using the Wiki User Profile. Just click on your login Id at the top of the screen to edit your wiki profile... see User: red1 as an example.

To work on Support Requests, Bug Reports & Patches and maintain their status within SF you will require specific access granted; contact Low Heng Sin or Colin to organise this.

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 so it's not already reported, what now? Well, if you are new to the project then the best approach to take it create a SourceForge Support Request (SR) to highlight what you think is a bug and get a second opinion before creating a bug report.

If you are experienced and have no doubt as to the bug then you can create a Bug Report directly.

Some tips when submitting a new Support Request or Bug Report

  • Do provide a detailed information about your environment configuration: System Op., Adempiere version, DB, client used (i mean Gardenworld test or your client), etc.
  • Do provide the name of the specific window/report/process name where the problem occurs.
  • Do provide detailed steps to reproduce and if possible in the GardenWorld test client.
  • Remember the developers might not be versed in the daily business use of the application so, where applicable, provide a description of what you wish to achieve and what you expected to happen.
  • If an actual error displays include a copy of the log with error.


For a more detailed look at the QA Process see here. But let me just add here; this is a volunteer based organisation, people are free to choose what to do when, and that typically is something in line with their current job at hand. This means you might not get an immediate response to your submitted Support/Bug Report, or an immediate solution, but please do not be disheartened. The sheer size of the bazaar means that eventually others will also encounter your problem or require your submitted solution. So while it may sometimes not be immediate, everyone will get a response!

See Also