Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of lilyzhao8@gmail.com designates
 209.85.160.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F8B4A26.7040006@apache.org>
References: <4F6AF019.3020308@a-w-f.de>
	<4F746868.5080105@a-w-f.de>
	<op.wb2qtbl0gq6zng@pc-pc.belkin>
	<4F7828BA.3070703@apache.org>
	<4F79C620.2000002@a-w-f.de>
	<op.wb96ccgggq6zng@pc-pc.belkin>
	<014001cd134a$62b5c640$282152c0$@acm.org>
	<op.wcb0tzkugq6zng@pc-pc.belkin>
	<CAEtvNKdLbroNSHPusMqUfUYy4yr3YvN=O+GBSk00GTg82C_WrA@mail.gmail.com>
	<CAP-ksoj13E+a+eBFYT+as9FP0EDwOJwrZRA9pf0OFSHW8hMkkg@mail.gmail.com>
	<4F8AD852.5020800@apache.org>
	<CAP-ksoik9yubir7oGVVG55xmRiCj6UwykCKt6Tfm_whdFSWo1A@mail.gmail.com>
	<4F8AEE1E.2090402@apache.org>
	<CAP-ksoi4W0wSF20Zo2cHLAywsAErPYyWaif4XLZ1GF=xLwwTMg@mail.gmail.com>
	<4F8B4A26.7040006@apache.org>
Date: Mon, 16 Apr 2012 14:30:00 +0800
Message-ID: 
 <CAO+9X+UydKf-DVSx+dcpb6DBJDcJ6EbMWeDajhqspQ-2v29O6Q@mail.gmail.com>
Subject: Re: [RELEASE] Planning QA activities (was: Dictionary extensions)
From: xia zhao <lilyzhao8@gmail.com>
To: ooo-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e89a8ff24baba0cb7304bdc5f30b

--e89a8ff24baba0cb7304bdc5f30b
Content-Type: text/plain; charset=ISO-8859-1

2012/4/16 Andrea Pescetti <pescetti@apache.org>

> On 15/04/2012 Rob Weir wrote:
>
>> On Sun, Apr 15, 2012 at 11:49 AM, Andrea Pescetti wrote:
>>
>>> Historically, OpenOffice.org produced a numbered Release Candidate
>>> (OpenOffice.org 3.3 had ten, RC1 to RC10) that was made available to the
>>> community exactly for the purpose of looking for unknown bugs. QA
>>> activities
>>> were planned for the RC phase and, after a few days of availability, a RC
>>> was approved as final or rejected (and the Release Manager could, and at
>>> times did, include fixes for previously known bugs that had been
>>> accumulating and that were significant; none of them was a blocker in
>>> itself, but each of them would have caused problems to users, so their
>>> combined effect was blocking the release).
>>>
>> That is what we've been doing with the dev snapsots builds.  Surely
>> you've seen the QA work Lily has done with testing them?
>>
>
> Sure, and it was great work. But those tests were run on versions that are
> now quite outdated. Example: the spell check test asks you to verify that
> no spell check is available and that dictionaries have been removed
> accurately, while we all know that things are quite different in current
> builds.
>

How do you means "tests were run on versions that are now quite outdated"?
We are doing regressiont testing continuously. Switch build do different
feature regressiont esting. For RC build, I don't think the fulll
regression is reasonable, more important, it is instalation, extenson, plus
some small regressiont testing. The full regressionte testig should be done
before one RC build is ready for vote.

>
> The traditional OpenOffice.org Quality Assurance process had two features
> that I'd like to keep:
>
> 1) Full QA is run on what we release. We need to ensure that OpenOffice
> works now, not that previous builds worked.
>
   Agree if the "Full" here means  test matrix on full platforms and full
langauges. The "OpenOffice" you means here I understand is AOO. For AOO,
the problem is we lost manual test cases, so general regression testing is
done against AOO builds. I belive these testing results can be taken as
evidence of what AOO works now.

>
> 2) The community at large is involved in testing, in a specific short
> period just before the release. If "Release Candidate" has a different
> meaning now, call it the "Pre-Release Phase", that will end with a "Release
> Candidate" we can vote on rather confidently. We can't rely on volunteers
> doing QA on a regular basis, but we can very easily find volunteers willing
> to stress-test a "nearly final" version in a well defined timeframe (1-2
> weeks).
> I agree you on this point ans it is what we do now. You may check the RC
> build testing plan. QA volunteers will testing RC build for one week,
> meanwhile, all volunteers can do stress-test against RC build before he/she
> gives vote.
>

   Lily


> I would keep this as a basis for discussing how to structure QA activities
> in future (after 3.4), if others agree.
>
> Regards,
>  Andrea.
>

--e89a8ff24baba0cb7304bdc5f30b--