Difference between revisions of "QATrack"

From Apache OpenOffice Wiki
Jump to: navigation, search
(New page to describe QATrack in term of processes)
 
(First steps)
Line 1: Line 1:
 
[[Category:Quality Assurance]]
 
[[Category:Quality Assurance]]
<div style='background-color:rgb(90%, 90%, 70%); padding: 10px; '>
 
''Original proposal by Andrea Pescetti - please discuss below rather than editing this box.''
 
__NOTOC__
 
I will realize a new web-based tool for tracking QA of localized
 
OpenOffice.org builds. It will feature clear, informative and
 
attractive screens for the general public, easy management and
 
updating, IssueZilla integration, notification by e-mail and RSS
 
feeds and easy extensibility.
 
  
=== Overall description ===
+
[http://www.qatrack.org/ooo QATrack] helps the OOo community during all steps of the QA
The tool will help the OOo community during all steps of the QA
+
process for localized builds.
process for localized builds. The focus will be on having a system,
+
easy to use and maintain, for the QA volunteers and on guaranteeing
+
fast and reliable diffusion of information to the general public.
+
  
The tool will automatically maintain a main page, which summarizes
+
The tool automatically maintains a status page, which summarizes
the status of every build, and specialized subpages. It will assist
+
the status of every build, and specialized subpages. It assists
 
in every step of the QA process as follows.
 
in every step of the QA process as follows.
 +
 +
The original design and history of QATrack is at [[Release QA Tracking Tool]].
 +
 +
=== Get a QATrack account ===
 +
For the time being, you will need to get a separate QATrack account, different form the ones you use to login to the OpenOffice.or website or to TCM.
 +
 +
Native Language project leads can e-mail dev@qa.openoffice.org to get a QATrack account. Please specify the language code for you NL project.
 +
 +
=== Find your builds ===
 +
 +
QATrack lists available builds from many providers. You will be automatically be notified by e-mail and RSS when a new build in your language is available.
 +
 +
If you cannot see the build you wish to QA even though it has already been available for some days, e-mail dev@qa.openoffice.org with your request.
 +
 +
If you build OOo yourself, please ask for "Build provider" status in QATrack so that you can upload builds as soon as you make them available.
 +
 +
=== Mark builds as "IN QA" ===
 +
 +
You can edit the build status for builds in your language.
 +
  
 
Step 1:
 
Step 1:

Revision as of 12:57, 17 December 2006


QATrack helps the OOo community during all steps of the QA process for localized builds.

The tool automatically maintains a status page, which summarizes the status of every build, and specialized subpages. It assists in every step of the QA process as follows.

The original design and history of QATrack is at Release QA Tracking Tool.

Get a QATrack account

For the time being, you will need to get a separate QATrack account, different form the ones you use to login to the OpenOffice.or website or to TCM.

Native Language project leads can e-mail dev@qa.openoffice.org to get a QATrack account. Please specify the language code for you NL project.

Find your builds

QATrack lists available builds from many providers. You will be automatically be notified by e-mail and RSS when a new build in your language is available.

If you cannot see the build you wish to QA even though it has already been available for some days, e-mail dev@qa.openoffice.org with your request.

If you build OOo yourself, please ask for "Build provider" status in QATrack so that you can upload builds as soon as you make them available.

Mark builds as "IN QA"

You can edit the build status for builds in your language.


Step 1:

  • Localized builds are made available by known providers via the tool
  • Links to the (untested) builds appear on the main page
  • Interested Native-Lang QA Leads are informed by e-mail and RSS

Step 2:

  • A Native-Lang QA Lead notifies beginning of tests to the tool
  • The build appears as "In QA" on the main page
  • If possible, links to the suitable TCM pages are provided (to authorized users and for supported locales) to track QA progress
  • Optionally, a closing date for tests can be specified and shown

Step 3-A (if the build passes tests):

  • The QA lead notifies success to the tool
  • The build appears as "QA passed" on the main page
  • The QA lead, assisted by the tool with a pre-filled IssueZilla template, notifies success and asks for distribution to mirrors
  • A notice appears in RSS feeds to inform about approval
  • When the distribution issue is closed, the QA lead notifies the tool
  • The build appears as "Released" on the main page
  • Download link is optionally changed
  • E-mail notifications and RSS feeds inform of the release availability

Step 3-B (if the build fails tests):

  • The QA lead notifies failure to the tool
  • The build appears as "QA Failed" on the main page
  • Links to the blocking (global or localization) issues are shown on the page
  • A notice appears in RSS feeds

Tool description

Main page for the general public:

  • A table will summarize all information about builds for each language and platform
  • Default sorting will be by language (English first, then all languages for which a localized build is available, then all other languages); other sorting options will be available
  • Subpages will be available for the single builds; they will contain more verbose descriptions and more detailed information

There will be three types of users:

  • ADM, Administrators: add languages/platforms, manage users
  • BPR, Build providers: provide localized binaries for testing
  • QAL, Native-Lang QA Leads: one or more per language, report test results

ADMs have access to the Administrative interface, providing:

  • User management: ADMs can add/modify/remove any user
  • Language management: ADMs can add new language name/code pairs
  • Platform management: ADMs can add new platforms
  • Moreover, an ADM has all BPR and QAL privileges

BPRs have access to the Build submission interface:

  • BPRs can inform about builds in progress and set the "Build in progress" status for platform/language pairs
  • When builds are ready, BPRs publish them through the tool
  • If a new build is submitted and an older one is still in QA for the same language and platform, both builds will be displayed on the main page
  • Every time a new English build is submitted, all BPRs are notified through the usual channels (e-mail, RSS feeds)
  • The tool supports simultaneous submission of many builds for the same platform via wildcards or heuristics
  • Optionally, mirror sites for the same build can be specified

QALs manage the rest of the process:

  • QALs can add new QALs for their language, in order to delegate work
  • QALs interact with the tool in all steps of the process
Personal tools