Hi Tora, *,
On Sat, Dec 16, 2006 at 12:01:21PM +0900, Tora wrote:
> Charles-H.Schulz wrote:
> >here is a very, very small and rough draft of the page. As Thomas
> >suggested I put it on the wiki:
> >http://wiki.services.openoffice.org/wiki/NLC/localizedQA
>
> Great. It clearly states what we should do on our localized builds
> to distribute them to the local market.
>
> I am not sure that the following idea could be put in the same page
> or in the separated page. It is a position of the local test within
> the development process of OpenOffice.org. Have a look at schedule
> in the web page http://wiki.services.openoffice.org/wiki/OOoRelease21 .
>
> ==============================================================
> * UI Freeze : October 5th 2006 (New !! all new strings need ...
> * Feature_freeze : October 12th 2006 (New !! New features ...
Hmm. Is it just me or would it be more logical to have feature freeze
before UI-Freeze?
(I guess it doesn't matter anyway since it was only one week's timeframe
- too short for a cws-turnaround anyay)
> [...]
> One thing that we could consider:
> The primary and language independent functionalities had been tested
> by development team and QA team before our local test.
Well, even in language independent functionality there may be errors
that only show up in certain localizations.
If I take the PDF-Export for example, some (at least en-GB and en-ZA)
localizations have missing translations/strings in that dialog.
> What had not
> been tested so far? What is difference among local environments?
> That would be keyboard, input method, font rendering,
Font-rendering would be a thing that I would consider localization
independent, as are the input stuff, but however it is far easier to
test for someone who is familiar with the language (hard to tell whether
that arabic or hebrew text is rendered correctly for the "average
european")
> date-time-currency format,
> printing to printers that locally purchased, interoperability
> with competitor's software turned and tweaked to the local market,
> and so on.
Yes, the local market thing (localized OS, special third-party
software, even different hardware,...) could make big difference,
however this is again not something I would place in "localized" QA,
since the problems that would occur in this environment would likely
occur with the english version as well. (It is however very important to
check this nevertheless)
> We should test language dependent functionalities sometime during
> the entire development process. But, they obviously should not be
> done at release test. It is too late and time consuming. But, but,
> if nobody had tested them at all, some of them should be tested
> before giving OK to our local builds.
Yes, thinks like the autocorrection table or other really language
dependent functions (like you mentioned date-formats) shouldn't really
change often - but Murphy tells that if you skip the test, then this
time some completely unrelated change (or some compile problem) will
have screwed that feature :-)
(Remember the builds with totally broken help-content?)
But no matter how much and how carefully you test, somebody will always
find a new crasher or some other annoying problem that could have be
detected if only somebody opened that dialog with this or that
prerequisites...
It's hard to find a balance and write something like "You only need to
test this and that", It's easier to write: "At the bare minimum, you
should run the following tests"
(the old smoketest in the early days, now the release-sanity & relatec
szenarios in TCM)
ciao
Christian
--
NP: Dimmu Borgir - Dødsferd
Join #qa.OpenOffice.org on irc.freenode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
