Issue hunting party
The Issue Hunting Party is used by the QA project to work concentrated on special tasks in the QA project. The first chat was used to reduce the number of open 'unconfirmed' issues. It is planned to give the Parties always a special topic like 'working on fixed/verified issues', 'bug hunting on new features' etc.
The Issue Hunting Parties will take place on IRC on freenode in channel #qa.openoffice.org. It should be every first Tuesday in a month. The announcements about the topics will be taken on the qa @ dev.openoffice.org mailing list and in a blog on http://blogs.sun.com/gullfoss.
- 1 Issue hunting party 9th of September 2008
- 2 What should be doen
- 3 Issue hunting party 5th of August 2008
- 4 Issue hunting party 15th of July 2008
- 5 Hint
Issue hunting party 9th of September 2008
The regular issue hunting party from 2nd of September is shifted to the 9th because the first release candidate shifted too by one week.
Now the 1st release candidate of OOo 3.0 is released and the QA community will check if last show stopper issues could be identified or if the release candidate is possibly the final version. So check all fixed, verified and integrated issues and if possible also all new incoming issues based on this version.
What should be doen
The 1st release candidate is build OOO300m5. You can download it at : http://development.openoffice.org/releases/3.0.0rc1.html
The queries for all fixed/verified and integrated issues are :
all opened fixed and integrated issues on the way to OOo 3.0 => starting number = 807
for component Word-Processor (Writer) only starting number = 73
for component Spreadsheet (Calc)/Chart only starting number = 101
for component Database only starting number = 75
for component Framework only starting number = 159
for component Graphics (Presentation/Drawing) only starting number = 45
Issue hunting party 5th of August 2008
Some weeks before the first release candidate of OOo 3.0 will be go live, the QA project will check the general quality of the new features, of the bug fixes etc. in this 24 hours live chat. There are a mass of opened fixed and verified issues for this release. All these issues are integrated in OOo 3.0 code base. They are checked in a Child-Work-Space (CWS) and now these issues should be checked in the master build.
What should be done :
- check the issue in build DEV300m28 or OOO300m1 (if it is live until the chat begins)
- do not check the issue in build DEV300m29, because this is the code base for OOo 3.1 and there are some CWSes integrated, which aren't for OOo 3.0
- if the issue is fixed and correct integrated it has to be closed
- if the issue isn't fixed it should be set to 'reopened' and the target should be checked
- if the bug is important for a new feature or for the general functionality it should be set as shows stopper for OOo 3.0
- if the bug is a nice to have, than the issue should be set to target 3.x
- it's best to discuss the target in the chat
- if other issues are identified beside the testing of an fixed issue, it should be written as a new issue and the target should be handled like described above
- take also a look to the hints at the end of this wiki page
all opened fixed and integrated issues on the way to OOo 3.0 => starting number = 962
for component Word-Processor (Writer) only starting number = 125
for component Spreadsheet (Calc)/Chart only starting number = 151
for component Database only starting number = 87
for component Framework only starting number = 178
for component Graphics (Presentation/Drawing) only starting number = 66
After the 24hr this session can be called a success. Lots of community members from all over the world closed nearly 150 issues during the session and in the following hours. Some regressions were found and a handfull of new task were submitted. The IRC log can be found here.
Issue hunting party 15th of July 2008
The focus on this chat was to reduce the number of 'unconfirmed' defects in IssueTracker.
Working on 'unconfirmed' defects
The QA team should take always a look at the unconfirmed defects. These are the new incoming issues, which aren't re-checked by a community member of the QA project. If the issue is valid it has to be set to state 'new'. Perhaps the summary should be adapted to a more feasible meaning and if possible the description should be shortened to a useful and clear description.
- unconfirmed defects in Framework => starting number = 412
- unconfirmed defects in Writer => starting number = 319
- unconfirmed defects in Spreadsheet/Chart => starting number = 295
- unconfirmed defects in Graphics (Presentation and Draw) => 26
- unconfirmed defects in Data Base => 49
- unconfirmed defects in other components => 281
Please take also a look at the blog by Thorsten Ziehm from Friday, 11th of July 2008. There you will find also links for the submission date of the 'unconfirmed' defects. http://blogs.sun.com/GullFOSS/entry/status_of_unconfirmed_defects_in
The overall number at startup of the chat : 1376
The overall number at the end of the chat : 1263
The number of issues could be reduces by more than 110 issues. If you add also the new incoming issues from that day on more than 120 issues was worked.
Working on 'fixed/verfied' issues
Working on fixed and verified issues (in a [CWS]), which are integrated into the product. A final check if there as still and also fixed in the final product is needed. If it is, than close the issue.
fixed and integrated issues in OOo 2.2.1 and older versions of OOo 2.x => starting number = 3
fixed and integrated issues in OOo 2.3/OOo 2.3.1 => starting number = 221
fixed and integrated issues in OOo 2.4/OOo 2.4.1 => starting number = 383
fixed and integrated issues on the way to OOo 3.0 => starting number = 889
The numbers doesn't changed in that chat. The focus was on reducing the 'unconfirmed' issues.
- You can edit the query, when you click on the link in the list. After that scroll to the end of the list and click 'Edit this Query'. For example than you can add the 'component' of your choice.
- some issues are 'developer issues', which cannot be verified easily by a QA person. So do not invest so much work in such issues.
- issues from QA persons by Sun can be verified often more easily (who are the QA persons there?)
- it is better to start with the newest issues, because they aren't often checked by a QA until now; older 'unconfirmed' issues are often checked by many people, but nobody take the responsibility to close the issue or send it as valid issue to a developer