Difference between revisions of "Testing my translation"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Created the page)
 
m (2. Release testing)
Line 78: Line 78:
 
<br>
 
<br>
 
* '''Timeline: product release'''
 
* '''Timeline: product release'''
<br>
+
 
<br>
+
 
or it may not, depending on your resources, and the problems you have encountered. The goal is to release OpenOffice.org in your language, at a high level of quality. It is much better to release some days, or even weeks after the planned release date, than to release a lower-quality version on time.
 
or it may not, depending on your resources, and the problems you have encountered. The goal is to release OpenOffice.org in your language, at a high level of quality. It is much better to release some days, or even weeks after the planned release date, than to release a lower-quality version on time.
 
<br>
 
<br>

Revision as of 08:20, 10 January 2007

When do you need to test your translations? There are two stages to testing, or QA (Quality Assurance) for OpenOffice.org Native Language Projects (NLC).

  1. Translation testing (focusses on language)
  2. Release testing (focusses on function)

1. Translation testing

starts as soon as you have some strings translated.

  • Timeline: new strings have been released in the latest milestone.

Summary: merge new strings, update translation, check for errors, submit translation

Tools: translation editor (e.g. Kbabel, Pootle), gsi-check, Translate Toolkit, Issue Tracker

So you update your strings, and start checking them. You should always be checking the quality of your translated strings, checking for errors, and consulting with your team-mates on how to create the best translation. This type of testing should occur well before the release date. It is your opportunity to work on the best possible translation.

Tools for eliminating errors in your translation include gsi-check and the Translate Toolkit. Once your completed file is thoroughly checked, you upload it, and include that link in an issue you create in the Issue Tracker to submit it, before:

  • Timeline: the deadline for submitting your translation

Summary: basic checks: test early builds, implement early fixes
Tools: build mirrors, TCM, Testtool, Issue Tracker

At this point in the release schedule, it seems as though there is a lull before testing builds are provided. In fact, helpful people like Pavel and Maho provide regular builds based on your available files, so you can supply them with a link to your current file, provided it is checked and ready to test, even before officially submitting your translation, and you will have builds available for testing.

This early test phase should still be directed at the language of the build. For example:

  • Does each menu and dialogue display correctly?
  • Do font effects work?
  • Does the installer display correctly?
  • Does autotext work?
  • Are the supplied format strings correct?
  • Does spellchecking work?
  • Is the dictionary adequate?

Testtool has a routine which provides a screenshot of each menu and dialogue, which can help you scan for errors. The numbered tasks in TCM for each component of OpenOffice.org (e.g. Writer 1) take you through many situations where you can check the display of menus and dialogues. This is your chance to check all these things thoroughly. Submit issues for errors in Issue Tracker, and track their solution. Report and eliminate as many errors as you can, and update your current translation file with any necessary changes, at the link submitted for this release.

2. Release testing

starts as soon as translated CWS builds appear on the main OpenOffice.org servers, e.g. oootranslation.services. From this point, there are no changes in the OpenOffice.org code, other than fixes for problems found. This makes it possible to test fairly rigorously for function, since that function isn't going to change between builds. At this stage, the original strings, the translation and the program code have all been frozen in this version of OpenOffice.org, except for fixes.

  • Timeline: l10n CWS builds available

Summary: functional tests, test translated CWS builds, implement fixes

Tools: TCM, Testtool, Issue Tracker, QATrack

This later test phase should be directed at the function of the build. Does OpenOffice.org function properly in your language, when doing all the tasks a user would expect it to do? Complete any of the numbered component tasks (e.g. Writer 1) still unfinished in TCM, and start the release-sanity and automated tests. Run Testtool. Update the status of each build in QATrack. Report and eliminate problems. Create an issue in Issue Tracker which summarizes progress in testing up to release, attaching results files, e.g. from testtool. Get the last pre-release changes into your uploaded file (as linked to your submission issue) before:

  • Timeline: last CWS integration for fixes

Summary: ongoing functional testing, help eliminate functional issues

Tools: TCM, Testtool, Issue Tracker, QATrack

Continue the functional testing. Make sure reported issues are being resolved. Co-ordinate between different testers to make sure the results are coherent, and that all tasks are covered before anyone repeats the same test. Duplication reinforces your results, but it's much more important to get two different tests done, than it is to do one of them twice. Collate feedback from users running the testing builds. By now, if you have sufficient resources, you should have an overview of the status of your translated builds. Are there any remaining "stopper" issues, issues severe enough to block release? If so, concentrate effort on these issues.

  • Timeline: release candidates for all languages

Summary: final functional testing, prepare for authorized release

Tools: TCM, Testtool, Issue Tracker, QATrack

The servers will now provide Release Candidate (RC) builds in your language. These are final pre-release builds. You do not need to begin testing again with each different build: you can concatenate your results. So continue your testing with these RC builds, concentrate on any remaining serious issues, and finalize your results. Keep the status of your builds up-to-date in QATrack, so it is easy to see the QA progress, and each stage towards release. As the release date gets closer, make your decision on whether each build can be released yet, or not. When a build is ready for release, submit an issue authorizing its release. This may occur before the

  • Timeline: product release

or it may not, depending on your resources, and the problems you have encountered. The goal is to release OpenOffice.org in your language, at a high level of quality. It is much better to release some days, or even weeks after the planned release date, than to release a lower-quality version on time.

See also:

Personal tools