Hi, I almost missed your mail. When I got no response to my offer, I thought there was no interest. Our testers use TestLink (http://www.teamst.org/), so the test cases currently live inside that. From the manual it seems, that one can only export to XML. Which format would you prefer? Other than that, I still need to ask for permission to share the test cases. It would help, if I could demonstrate serious interest by the community to put the tests to good use.
Greetings Andor Ertsey On Wed, Dec 7, 2011 at 8:54 AM, xia zhao <[email protected]> wrote: > Andor, > > It will be much appreciated if you can share it with free license. And we > can see if some volunters can contribute to the translation. > > Hope your response. Thanks. > 2011/11/24 Andor E <[email protected]> > >> Hi, >> for our project we have a sizeable amount of manual test cases for >> OpenOffice.org (created by professional test engineers). These are >> used for internal and user tests before a release. If there's a >> serious interest in it, I might be able to arrange a release of these >> test cases under a free license (creative commons?). They are written >> in German, though, and would need to be translated first. >> >> Greetings >> >> Andor Ertsey >> >> On Wed, Nov 23, 2011 at 4:31 PM, Rob Weir <[email protected]> wrote: >> > On Wed, Nov 23, 2011 at 2:58 AM, xia zhao <[email protected]> wrote: >> >> 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: >> >> >> > >> > Hi Lily, Thanks for the proposal. >> > >> >> 1. Leverage OpenOffice users on General Usage test >> > >> > >> > For this to work we need: >> > >> > 1) Test cases that are clear and easy to understand >> > >> > 2) Test cases that can be run without requiring a lot of preparation >> > >> > 3) Test cases that can be run without dedicating much time. How can >> > someone help who has only 1 hour to contribute? >> > >> > 4) Test cases that can be run without learning a lot of other tools or >> processes >> > >> > >> >> 2. Focus on establishing automation mechanism. Start from Build >> >> Verification Testing(BVT in short). >> > >> > Is the the same as a "smoke test"? >> > >> >> 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. And then report defects in >> >> Apache Bugzilla. >> > >> > Maybe we also need a "guide to writing test cases"? Or point to >> > something that already exists for the project. >> > >> >> 4. Focus on Performance Verification Testing(PVT in short) >> >> investigation, and setup benchmark PVT environment. >> > >> > OK. >> > >> >> 5. Establish QA entry in AOO wiki https://cwiki.apache.org/ >> > >> > OK. >> > >> >> 6. Build private build before official build is ready >> > >> > OK. >> > >> >> 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 >> >> - FreeBSD 9.0/8.2 (9.0 is suppose to release at 12/07/2011?) >> >> - OS2 >> >> >> > >> > For platforms, maybe we think about them like this: >> > >> > 1) In order to preserve the value of the OpenOffice brand among users >> > and our reputation for high quality, we will have an official Apache >> > binary release only on platforms that have successfully completed the >> > QA plan that we all agree on. >> > >> > 2) Volunteers, based on their interests, will determine which >> > platforms are officially supported in releases. >> > >> > 3) Platforms that do not have enough volunteers to complete the test >> > plan would not have official Apache releases. Or if we had releases, >> > they would be called "experimental" or some other name to indicate >> > that they were not fully tested. >> > >> > 4) Of course, anyone is welcome to take our official source releases >> > and make a build on another platform and distribute it. But these >> > would not be official Apache releases. >> > >> > -Rob >> > >> >> Welcome your comments. >> >> >> > >>
