For all the new QA volunteers, if you have not met Juergen, he is one of our developers and also acts as "release manager", taking care of the logistics involved in approving and releasing new versions of OpenOffice.
If anyone wants a break from confirming user defect reports, this will be a good opportunity to try verifying fixes in a snapshot build of AOO 4.0, in a couple of weeks. To do this you would review a list of bugs that were marked as fixed in 4.0, and test to make sure they actually were fixed. In most cases they will work fine. In some cases they will still be broken. And in some cases the main bug was fixed, but a new one was introduced. Developers are not perfect. (No one is.) So it is important to "test around" any fixed bug. What does that mean? It means to "think like a bug" and try to break the product. Let's take a simplified example. Imagine you had a dialog box for adding new sheets to a spreadsheet. It had a simple edit box where you entered how many sheets to insert. How would you test this? Would you just enter "5" and if it works, mark the feature as working? No. You want to think like bug, and imagine the kinds of errors that could occur. For example: 1) What happens if you enter 0? 2) What happens if you enter -1? 3) What happens if you enter an extremely large number? 4) What happens if you don't enter any number at all, or delete the default entry and just press OK? That is thinking like a bug. A good tester develops a sense for how code breaks. Regards, -Rob On Thu, Jan 24, 2013 at 10:09 AM, Jürgen Schmidt <[email protected]> wrote: > Hi, > > Herbert (thanks again) has prepared this nice script to retrieve issue > numbers from the svn logs between 2 revisions. He created a new update > and the list [1] shows many issues that went into trunk since the 3.4 > release. > > You can see some issues already have a correct target field, some are > merged from the 3.4 branch (no changes for the target necessary) and > some have no target field set. > > These issues should be reviewed and verified on a trunk version (nightly > or next snapshot build that we will prepare after FOSDEM). > > The target field have to be set for many issues as well but this > requires further rights... One reason is that we don't that everybody > can set his own most important issue for the next release ;-) > > The main idea for now is to verify the fixes on a trunk build. > > I think this is a good opportunity to get started. > > Juergen > > > [1] http://people.apache.org/~hdu/izlist9.htm
