Skip to content

start:

QA Process for Localized Builds

This process is in progress, and as better processes become apparent, we will follow them and change this guideline. The testing of the builds deeply involves the QA and Native-Lang projects. Notices pointing to this process guideline will be posted on those projects and also on the l10n project.

Where do the localizations come from?

Localized builds are created by the community. The l10n project coordinates this activity, and one can view the status of any ongoing localization by checking the status page.

What do we do here, in QA?

The point of having QA test these builds is to reduce the possibility that the builds won't work. They may still be rough, but by going through the QA process, we can at least ensure that we won't be sending out to the world builds that can't be installed, won't work at all, ...

What is the QA process?

  • Localized builds are made available at several places. These are: QA project is trying to provide a list of those URLs for these builds at the status page. But for most current information about the availability of such builds you should subscribe to the relevant mailing lists (releases@openoffice.org, dev@porting.openoffice.org)
  • The builds are listed on the Status page. This page needs to be updated by the people working on the build to indicate the status (builds in progress, untested build available, in QA, release approved, release published).
  • Native-Lang leads or their delegates assigned to the task of helping QA the builds download the builds and run through a series of tests. This process should begin immediately upon the availability of localized release candidates and should not take more than two weeks from beginning to end. For managing those testcases, test assignemnts and results we use the TCM (Test Case Management) Portal
  • Once a localized build has been tested and it has passed the tests, then its entry on the Status page should be updated.
  • An IssueTracker ticket should be filed so as to move the tested builds over to the /localized directory for proper downstream dissemination and to update the pages. Mirrors need to be notified by the Distribution project lead.
    This should be filed as "Task" for Componente "qa", subcomponent "www". Assign it to the default owner and make shure, you name the exact location of the files that have been used for testing.
  • Finally, once the mirror network has indicated that the builds have been successfully uploaded into the proper directory, the builds may be announced by the appropriate persons, such as the Native-Lang leads and Community Manager.
$Revision: 1.16 $