incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Calling all volunteers: It is time to test
Date Wed, 29 Feb 2012 14:18:21 GMT
As we approach the first Release Candidate for Apache OpenOffice 3.4,
it would be wonderful if we could have some more volunteers testing
the latest dev snapshots builds. Following is some information on what
this requires, and how you can help.

First, if you have never tested a pre-release product before, know
that bugs are expected. That is the purpose of testing, to find bugs
so they can be fixed. Bugs could range from UI glitches, to incorrect
formatting to crashes or even data corruption.  So you probably don't
want to use a test build for mission-critical tasks. Of course, I
assume you have already backed up your important documents.  You do
have backups, right?  Ideally you can do your testing on a separate
machine from your main work machine, so if something goes wrong you
will not interfere with your other work.

The above are all sensible precautions when testing any pre-release
software product.

If you are ready to test, you can download the latest developer
snapshot build from this page:

We could use help verifying the install in all real-world scenarios,
on clean OS installs, as upgrades to previous versions of OOo and as
installs on machines where LibreOffice or Symphony are already

Once you have installed, launch OpenOffice and look at the Help/About
box.  If the revision shown there matches the build you installed
(e..g, "r1293550") then the install was a success. Please send a short
note to the telling us what platform and
scenario you installed (fresh install, upgrade, install next to
LibreOffice, etc.).  This will help us understand what scenarios have
already been attempted and which have not.

After you have installed, there are three approaches to testing, of
increasing degrees of formality:

1) Just use the dev snapshot for your ordinary work, doing your
ordinary tasks.  When you observe a bug, submit a report on this to

2) Self-directed testing.  Pick an area of the product that you
understand well, like printing or text formatting, or slide show
transitions.  Spend an hour or two trying to exercise that feature in
all its variations.  If there is a dialog box, try manipulating all of
its values.  If it is a formatting option, create a document that uses
all variations.   Try to break it.  Try to think like a bug.

A special area that could use attention is version compatibility.
Take all of your 3.3 documents and open them up on AOO
3.4.  Any errors?  Formatting issues?  Crashes? Missing data?   Ditto
for opening Microsoft Office documents.  Are there any regressions,
e.g., things that worked in 3.3 but now break in 3.4?  Try it in the
other direction as well.  If you create a document in AOO 3.4, can it
be read correctly in OOo 3.3?  Did we do anything that breaks
backwards compatibility?

Another special area is to verify the translations.  Install a
multi-language install or a language pack and check the translation
for completeness and accuracy.  If it looks good, please send a note
to the list, so we know it has already been verified. If there are
bugs, please enter into Bugzilla.

3) Cover test cases from the test plan

A 3.4 test plan is on the wiki here:

Results are here:

Look for an area that has not been tested, test it, and upload your results.

In all cases, if you find bugs, report them in Bugzilla:

We can also use help re-testing bugs that have been marked as fixed,
and confirming/reproducing newly reported bugs.  If you want to help
in Bugzilla, sign up for an account and respond to this note and ask
for your ID to be put in the  "qa-team" group, so you will have
expanded permissions to edit issues.



View raw message