Difference between revisions of "NLC/localizedQA"
(added Release Action List link) |
(moved one sentence to the beginning) |
||
| Line 3: | Line 3: | ||
'''Testing your localized builds''' | '''Testing your localized builds''' | ||
| − | Each Localization team or Native-Language project should, regardless of its resources, time and manpower, run some QA (Quality Assurance) tests on its localized builds. | + | Each Localization team or Native-Language project should, regardless of its resources, time and manpower, run some QA (Quality Assurance) tests on its localized builds. The testing is required if you want the localized builds to be distributed on OpenOffice.org mirrors worldwide. |
OpenOffice.org has a project dedicated to [http://qa.openoffice.org Quality Assurance]. | OpenOffice.org has a project dedicated to [http://qa.openoffice.org Quality Assurance]. | ||
You do not need to participate in the QA tests of the software itself, although your contribution is welcome. But you are requested to test your localized builds. The QA project has several tools both inside and outside the OpenOffice.org website. | You do not need to participate in the QA tests of the software itself, although your contribution is welcome. But you are requested to test your localized builds. The QA project has several tools both inside and outside the OpenOffice.org website. | ||
| − | + | The workflow is as follows: | |
* The lead of the NL project registers users (testers) in the TCM and assigns them various test scenarios. (At least the "Release Sanity" scenario should be assigned once per platform). | * The lead of the NL project registers users (testers) in the TCM and assigns them various test scenarios. (At least the "Release Sanity" scenario should be assigned once per platform). | ||
Revision as of 14:12, 16 December 2006
Testing your localized builds
Each Localization team or Native-Language project should, regardless of its resources, time and manpower, run some QA (Quality Assurance) tests on its localized builds. The testing is required if you want the localized builds to be distributed on OpenOffice.org mirrors worldwide.
OpenOffice.org has a project dedicated to Quality Assurance. You do not need to participate in the QA tests of the software itself, although your contribution is welcome. But you are requested to test your localized builds. The QA project has several tools both inside and outside the OpenOffice.org website.
The workflow is as follows:
- The lead of the NL project registers users (testers) in the TCM and assigns them various test scenarios. (At least the "Release Sanity" scenario should be assigned once per platform).
- The testers make the tests, and enter the results in the TCM.
- The lead enters the status of the testing to the QAtrack
- After the tests have been done, you update the status page and file an issue in IssueZilla, stating that the build is ready for distribution. Use this link as template.
- Then you update your project page to announce the availability of your localized builds :)
Note: for all builds (RC1, RC2...., RCN) the tests are the same in TCM. Simply update the status of bugs in the current release.
Resources and links
