QA/BugHuntingSession/Organization

From The Document Foundation Wiki
Jump to: navigation, search

Usually BugHunting session are organized on the last alpha, the first beta and the first RC of the major releases. They are dedicated to find bugs on those specific versions and make sure that the final release will not show major problems.

Communication

One month before the week-end of the bug-hunting session, some preparation for communication is needed:

  • create the page on the wiki
  • create the banners that should be placed on
    • the wiki page
    • the wiki event page
    • the website
    • BugZilla
  • create a Redmine ticket containing the dates and a link to the page in order for Italo to issue a PR when he sees the time is best

15 days before make a new call for participation on lists and social media.

Session

The day before

  • Make sure the wiki page has all information
  • Make sure that MozTrap run is available
  • Make sure there is a mentor available on the page with his name and mail address
  • Make sure the release is not delayed, if it is:
    • point the testers to another release on master
    • communicate on the QA and Projects lists and on IRC
    • create a new run on MozTrap pointing to the right version.

During the session

  • Make sure there is always a mentor available
  • Make sure that cross communication is working
  • Check again the availability of the version to test and the links on the wiki page.
  • Organize testing sessions on a dedicated module or new major functionality (e.g test on Writer only for 2 hours)
  • Insist on that it's not a triaging session and anybody should concentrate on testing and reporting bugs only.

After the session

  • Remove the banners from
    • the wiki event page
    • the website
    • Bugzilla
  • Collect metrics on participants (also NLPs participation)
  • Collect metrics on bug reports, triage
  • Collect metrics on MozTrap runs
  • Thanks everybody for his participation on lists and social media

Sample first announcement blogpost

A new release of LibreOffice is coming up - so help to make it the best version ever! LibreOffice X.X is due to be released on XX XXX, and developers are busy working on new features and updates. With so many changes in the next version, we'd really appreciate your help finding bugs so that we can squash them!

To this end we'll be holding a Bug Hunting Session on XX XXX, from XX:XX to XX:XX UTC. Anyone can take part at any time - it's simple and fun! All you have to do is download the latest development release, try out the new features, and report bugs on our IRC chat channel. Even if you can only spare half an hour of your time, it's a great help to make LibreOffice better than ever before - and you can show off a badge like the one above!

So mark the date: XX XXX. We'll post more details on this blog soon, so stay tuned...

Sample second announcement blogpost

Help to fix bugs in the next version of LibreOffice, and make it the best yet! As we mentioned in (link), we are holding a Bug Hunting Session on XX XXX, and everyone is welcome to take part. All you have to do is:

  • Download the latest development version of LibreOffice X.X from (link)
  • Join our IRC chat channel on (link, with more info)
  • Try the new features in LibreOffice, including X, Y and Z
  • If you find a bug, tell us about it on IRC, so that we can investigate more

And as thanks for your help, if you find or confirm a bug we'll award you a Badge(link) that you can proudly show on your website, blog or social media.

The Bug Hunting Session will take place from XX to YY on XX XXX, so join us then - and thanks in advance for your help!

BHS small.xcf BHS large.xcf

Note: make sure you have the Vegur font installed.