So I'll share some beginner tips for QA.
What to look for
The easiest way for beginners to learn about QA is to do it! Operating Systems have lots of UI and GUI tools to test (especially Ubuntu MATE) so the first thing to do is:
- Think about what you want to test
- Plan a scenario of the expected outcome (a Test Case)
Say for instance, you want to make sure that when you click on 'Backup' in Control Centre, that the app loads and the look and feel is correct and any hotkeys (alt+f4) will close the window. A basic Test Case will look something like this:
- Click on System
- Click on Control Centre
- Scroll down the list
- Find 'Backup' and click it
- Backup program will launch
- UI will look correct and any GUI options open their correct menu/popup window
- Closing the window via hotkey is possible.
There are many things to look for in an OS and it isn't always easy to test it. The best way for QA beginners is to test the GUI programs and any combinations possible in their functionality. Take for instance, this bug I filed yesterday in Launchpad:
A simple logging utility combined with a program which generates log output. The best way to think about it is 'what happens if I do this'. Essentially this is what we call 'Exploratory Testing', which is testing without a defined Test Case of expected functionality but also not randomly running around trying to break something, it is still controlled.
Test any and all combinations that you can think of, but just because it happens once it may not happen again. So always try it more than once and see if it is reproducible. Then you can file a bug report.
How to file a bug report
Make it short, sweet, to the point and without any 'fluff' (ie, needless information that complicates reading the bug). Use numbered steps, the version of the OS (Ubuntu MATE 15.04 Beta 2) with the architecture (x86 = 32bit, x64 = 64bit) and the version of the program which has the bug.
This narrows down the problem and gives the developer what they need to attempt to reproduce it.
A picture is worth a thousand words
Always (always) when possible, attach a picture to the bug report. Sometimes, this is all that is required as the screenshot will be painfully obvious as to what the bug is and where it is. Developers hate bad bug reports, so help them out a little, they are not magic wizards who know how to read bad reports
Testing an OS also requires some technical ability for the deeper elements, I won't go into it here as it would assume the tester has the required technical ability (and it will be a much longer tutorial). I hope these little bits of advice are useful.