incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [AOO 3.4 Test Plan Discussion]Overview
Date Wed, 23 Nov 2011 19:55:18 GMT
There is more on this thread, but this is an useful message to tack some observations to.

 - Dennis

OT: QA is far more than testing.  Just saying.

PS: I think the Xia Zhao discussion post is great, and it is bringing out some terrific discussion
on something that needs to be foreseen.

<orcmid comments="in-line" />

-----Original Message-----
From: J├╝rgen Schmidt [mailto:jogischmidt@googlemail.com] 
Sent: Wednesday, November 23, 2011 01:16
To: ooo-dev@incubator.apache.org
Subject: Re: [AOO 3.4 Test Plan Discussion]Overview

On 11/23/11 9:48 AM, Raphael Bircher wrote:
> Am 23.11.11 08:58, schrieb xia zhao:
>> Hi all,
>> I think it's time for use to discuss and detail AOO 3.4 test plan now.
>> Basically at current time I suggest:
>>
>> 1. Leverage OpenOffice users on General Usage test
>> 2. Focus on establishing automation mechanism. Start from Build
>> Verification Testing(BVT in short).
>> 3. Focus on test infrastructure set up. Start from case management tool.
>> For 3.4, place the test cases on wiki and volunteer can do general
>> testing
>> against. If volunteer couldn't write cases, may give the test scope he
>> would do. For example, which component etc.
> Sorry, forget Testcases. OOo is simply to big to test it with testcase.
> Testcases make only sense, if you can cover a software with it. What
> would be more usfull is a weekly journal of the changes. So Intuitive
> tester know where they have to search the bugs.

i disagree here, having a base set of tests that we should run for every 
release is important from my point view. I agree that it make sense to 
focus on areas where we have made changes, especially when we take the 
number of resources into account.

But anyway having test cases for at least the most important functions 
and features is a good idea and helps other people to easy get started.

<orcmid>
   I agree that being able to duplicate tests and test results is 
   important for newcomers to confirm their own builds and their own
   findings with documents that have problems, etc.  Everything to do
   with that kind of test is important to have available to beginners.

   In contrast, isn't it very difficult to do organized pre-released 
   manual testing in an open-source, volunteer-based project.  I can 
   understand how valuable it is to have automated tests to ensure that 
   something hasn't been broken and the build is sound.  

   And, of course, the place to look for regression is among the presumably-
   fixed bugs.  Are they really fixed (and are there automatically-
   executable test cases on the end-product that can determine that)?

   [Raised elsewhere on this thread] If it takes professional, paid QA
   for dependable releases to be created, this project will have failed.
</orcmid>


>> And then report defects in
>> Apache Bugzilla.
>> 4. Focus on Performance Verification Testing(PVT in short)
>> investigation, and setup benchmark PVT environment.
>> 5. Establish QA entry in AOO wiki https://cwiki.apache.org/
> why not use the original wiki http://wiki.services.openoffice.org wich

we have to clarify in general which wiki we want use in the future. I 
think this question isn't really answered but we shoidl open a new 
thread for this topic.

<orcmid>
   I don't think the OpenOffice.org wiki should be used for this.
   It looks like OOOUSERS is a better place.  Next would be OOODEV
   although I think experience has been that OOOUSERS is the 
   preferable place if possible.
      There could be a separate discuss for this, but I think CTR
   on OOOUSERS will happen.
</orcmid>

> is also at Apache now?
>> 6. Build private build before official build is ready
>> 7. Platform will be covered
>>
>>
>> - Windows XP
>> - Win7 32bit/64bit
>> - Where we only have a 32bit windows version, it should run against
>> 62bit windows version.
>> - Redhat 6 32 bit/64 bit
>> - Ubuntu 10.04 32 bit/64 bit
>> - Mac 10.7
>> - Mac 10.6.x
> We build against the 10.4 SDK so we also cover
> -10.5
> -10.4
>> - FreeBSD 9.0/8.2 (9.0 is suppose to release at 12/07/2011?)
>> - OS2
> If sameone is realy willing to do a OS2 port but it have to be serios,
> else I propose to not support this official.
>
  We have seen patches for OS/2 and if somebody is working on it it's 
fine. I think OS/2 won't be a blocker for us to release anything. I 
think the important platforms for us are Windows, Linux and MacOS, correct?

<orcmid>
   I think the platform cases are going to depend on who there are active
   developers and folks for the necessary localization, QA, etc.

   I do indeed expect that a 64-bit distribution will be required for
   Windows at some point.  It will have to be in addition to a 32-bit
   one for some time, especially because of any differences at 
   integration points for plug-ins, etc.  Side-by-side installation 
   will need to work also.  (I.e., both 64-bit and 32-bit.)

   That includes side-by-side with other distributions for that matter.
   That's a different topic though.

   This will be inevitable, and it depends on having supportive developers
   the same as any other platform choice.
</orcmid>

Juergen


Mime
View raw message