Difference between revisions of "QATrack"

From Apache OpenOffice Wiki
Jump to: navigation, search
(First steps)
(Whole process)
Line 25: Line 25:
 
=== Mark builds as "IN QA" ===
 
=== Mark builds as "IN QA" ===
  
−
You can edit the build status for builds in your language.
+
You can edit the build status for builds in your language. When you start TCM testing, please set the status to <tt>INQA</tt> for the builds being tested.
  
 +
You can optionally specify a closing date for your tests. This does not affect QATrack operation, it will just be displayed in the information box for that build.
  
−
Step 1:
+
You can delegate QA for a build to other QATrack users from your NL project. They will appear in the QA Contact field in the information box for that build.
−
* 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:
+
=== Test! ===
−
* 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):
+
Run the QA tests your NL projects uses (TCM tests or other). Get the final approval or rejection.
−
* 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):
+
=== Update the status page ===
−
* 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 ===
+
==== If the build is rejected ====
−
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:
+
Just mark it as <tt>REJECTED</tt> in the status page.
−
* 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:
+
==== If the build is approved ====
−
* 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:
+
* Mark it as <tt>APPROVED</tt> in the status page.
−
* BPRs can inform about builds in progress and set the "Build in progress" status for platform/language pairs
+
* Open an issue to request distribution to mirrors.
−
* When builds are ready, BPRs publish them through the tool
+
* Check that status changes to <tt>DISTRIBUTED</tt> (or change it yourself) once the build is distributed as stable.
−
* 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
+

Revision as of 13:09, 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. When you start TCM testing, please set the status to INQA for the builds being tested.

You can optionally specify a closing date for your tests. This does not affect QATrack operation, it will just be displayed in the information box for that build.

You can delegate QA for a build to other QATrack users from your NL project. They will appear in the QA Contact field in the information box for that build.

Test!

Run the QA tests your NL projects uses (TCM tests or other). Get the final approval or rejection.

Update the status page

If the build is rejected

Just mark it as REJECTED in the status page.

If the build is approved

  • Mark it as APPROVED in the status page.
  • Open an issue to request distribution to mirrors.
  • Check that status changes to DISTRIBUTED (or change it yourself) once the build is distributed as stable.
Retrieved from "https://wiki.openoffice.org/w/index.php?title=QATrack&oldid=22272"
Personal tools