Kdaj moramo preizkusiti naše prevode? There sta dve stopnji preizkušanja oz. QA (Quality Assurance) za projekte Native Language OpenOffice.org (NLC).
- Preizkušanje prevoda (osredotočena na jezik)
- Preizkušanje izdaje (osredotočena na funkcionalnost)
1. Preizkušanje prevoda
se začne takoj, ko ste prevedli kakšen niz.
- Časovnica: novi nizi so bili objavljeni v zadnjem mejniku.
Povzetek: spojite nove nize, posodobite prevod, poiščite in odpravite napake, pošljite prevod
Orodja: urejevalnik prevodov (npr. Poedit ali Kbabel), 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:
- Časovnica: rok za oddajo prevoda
Povzetek: basic checks: test early builds, implement early fixes
Orodja: 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. Preizkušanje izdaje
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.
- Časovnica: l10n CWS builds available
Povzetek: functional tests, test translated CWS builds, implement fixes
Orodja: 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:
- Časovnica: last CWS integration for fixes
Povzetek: ongoing functional testing, help eliminate functional issues
Orodja: 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.
- Časovnica: release candidates for all languages
Povzetek: final functional testing, prepare for authorized release
Orodja: TCM, SL/TestTool, Issue Tracker, SL/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
- Časovnica: izdaja izdelka
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.