Top 12 reasons to test the 2.4 release candidate - Ninja

Top 12 reasons to test the 2.4 release candidate

Posted by Andrew Z at Saturday, March 1, 2008 | Permalink

11. You scored #1 on Google Image Labeler and didn't even get a stinkin' t-shirt.
10. You live on the edge.
9. QA work looks good on your resume.
8. You can't remember the last time you learned something new.
7. To give back to the little people.
6. So you can brag about being under-appreciated.
5. Bugs suck.
4. To spite Bill.
3. To try the cool new features.
2. 2.4 will be the only release for six months. There will probably be no bug fix 2.4.1 release because developers will focus on 3.0. In other words, if it sucks for six months, you have only yourself to blame. We may blame you too. UPDATE: There will be a 2.4.1 but perhaps out of schedule. Bill Gates: I want you to go to something else right now
1. Testing skills are better than nunchuku skills, bow hunting skills, computer hacking skills... Girls only want boyfriends who have great skills[1].
0. It's so easy a child of five can do it.

With less than two weeks before 2.4 comes out (UPDATE: release date slips), now is the time to test the release candidate. If no bugs are found, the release candidate becomes the final version. Because is so large and complex, it is important for as many people to test it on as many systems as possible.

How to test

  1. The release candidate software is still experimental, so are your backups up to date? If you don't save over your existing documents, you should be safe. If you have a low risk tolerance, make a backup or quit now.
  2. Download and install the release candidate for Windows or Linux—or the Mac version.
  3. Test processes in the software you normally use. If you use mail merge, test mail merge. If you use math equations, test maths equations. If this is all you test, then great!
  4. Test the new features according to their test specifications (also called a test case).
  5. Test all the new enhancements.
  6. Check the QA site for more things test such as automation tests.
  7. If you find any bugs, search to check whether they are already reported.
  8. Register for an account in the Issue Tracker (the database of issues) so you can report bugs.
  9. Read the rules for reporting bugs.
  10. Report any new bugs.
  11. If you found any serious bugs (called show stoppers), report them to
  12. Don't expect small bugs to be fixed this late in the development cycle. Only show stoppers will be fixed for 2.4, and the rest will have to triaged until 3.0 or later.
  13. If you get stuck, check the QA web site or ask in the QA mailing list.
  14. (optional) In this post's comments, post a link to your bug report.

  15. Congratulations, you are a QA team member!

Related articles