Difference between revisions of "NLC/localizedQA"
m (Added reference to the Slovenian translation of this page) |
|||
| Line 36: | Line 36: | ||
'''Other Languages''' | '''Other Languages''' | ||
| − | [[Контроль качества локализированных версий|Русский]] [[Chất lượng bản địa hoá|Việt]] | + | [[Контроль качества локализированных версий|Русский]] [[Chất lượng bản địa hoá|Việt]] [[SL/NLC/localizedQA|slovenščina]] |
Revision as of 14:45, 28 December 2009
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. Want to join? Read the The QA Haiku!
The workflow is as follows:
- Builds to test appear in QATrack and NL project leads are notified by e-mail and RSS. If you wish to test a build which has not appeared on QATrack yet, send a request to the dev@qa.openoffice.org mailing list.
- 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.
In case full TCM tests are not possible because of lack of time or testers, you can follow the easier path with Sanity Check Of L10n Builds. You can skip then all TCM-related steps. Remember, though: the more tests, the less bugs in the software.
Resources and links
- Test Case Management
- QATrack description
- Release Action List for QA
- Testing my translation What? When? How?
- NLC:ReleaseChecklist#Test_your_localized_builds
- [Sanity Check Of L10n Builds]
- QA Process for Localized builds
Other Languages
