Difference between revisions of "NL/QA/SanityCheck van Localisaties"

From Apache OpenOffice Wiki
< NL
Jump to: navigation, search
(start)
 
(Een vergelijking van de Release Sanity test in TCM en de Sanity Check zoals hier beschreven)
Line 30: Line 30:
 
==Een vergelijking van de Release Sanity test in TCM en de Sanity Check zoals hier beschreven==
 
==Een vergelijking van de Release Sanity test in TCM en de Sanity Check zoals hier beschreven==
 
There is also a scenario in TCM (http://www.sunvirtuallab.com) that can be used for sanity testing. That one is more time-demanding than the steps described above - currently it contains 28 testcases. The TCM scenario is more suitable for testing Release Candidate builds, the steps described here are to be used for example for a quick check of interim L10n builds created between two translation handoffs (to make sure that strings from the first handoff were correctly imported into the builds).
 
There is also a scenario in TCM (http://www.sunvirtuallab.com) that can be used for sanity testing. That one is more time-demanding than the steps described above - currently it contains 28 testcases. The TCM scenario is more suitable for testing Release Candidate builds, the steps described here are to be used for example for a quick check of interim L10n builds created between two translation handoffs (to make sure that strings from the first handoff were correctly imported into the builds).
 +
 +
  (Deze pagina is een vertaling van [[Sanity_Check_Of_L10n_Builds]] )
 +
  
 
[[Category:NL.OpenOffice.org|QA]]
 
[[Category:NL.OpenOffice.org|QA]]

Revision as of 15:28, 10 May 2010

Deze pagina bevat een beknopte set instructies voor het uitvoeren van een sanity check op localisatie-builds.

 VERTALING in wording

Wat is een Sanity Check

Een sanity check is een snelle test van een build.

Waarom een Sanity Check nodig is

A sanity check is necessary to make sure that there were no errors in the building process. It is not supposed to go deep into the application functionality. Instead, it should focus on possible problems that are caused by errors in the building process and integration of translation into the builds.

Wat er bij een Sanity Check moet worden getest

This depends on how much time there is for the sanity check. As the usual period for the sanity check is quite short, the area that a sanity check can cover is quite limited. However, the following areas should be tested in every sanity check:

  1. Install the office suite
    Installation can be done successfully.
  2. Launch the applications
    All applications should launch correctly (Writer, Calc, Impress, Draw, Base)
  3. Check menus and dialogs
    Go through the menu structure and make sure that all menu items are localized. Open several random dialogs and make sure that they are localized as well.
  4. Open existing files, edit and save
    Use files containing localized characters. Try to edit them and then save them in various formats (ODF, MS Office, OOo 1.x) and reopen them to make sure everything is displayed correctly.
  5. Input localized text and format it
    There should be no problems when working with localized text. Try to create a short document containing localized text and some basic formatting settings (headings, tables, hyperlinks, ...).
  6. Check Help contents
    Open the Help, check the Table of Contents, the Index and make sure that searching works. Try to search for a localized string. Open several random Help pages and make sure that links in the Help pages work correctly.
  7. Uninstall the office suite
    Uninstallation can be done successfully.

Een vergelijking van de Release Sanity test in TCM en de Sanity Check zoals hier beschreven

There is also a scenario in TCM (http://www.sunvirtuallab.com) that can be used for sanity testing. That one is more time-demanding than the steps described above - currently it contains 28 testcases. The TCM scenario is more suitable for testing Release Candidate builds, the steps described here are to be used for example for a quick check of interim L10n builds created between two translation handoffs (to make sure that strings from the first handoff were correctly imported into the builds).

 (Deze pagina is een vertaling van Sanity_Check_Of_L10n_Builds )
Personal tools