Manual Testing help

What is Manual Testing?

When developing software, particularly larger pieces of software like say a whole operating system, you can often unintentionally add ​bugs and issues when you are adding in new features. When you break a pre-existing feature that was previously working correctly, this is called a ​regression. You can find regressions and software bugs in general by ​testing the software to see what is working and what isn't. This is done by either getting the computer to do it or by doing it yourself.

Because bugs and regressions can easily slip into software, it is important to test your software before releasing it. However if you don't have a predefined plan on what to test and how to go about doing it, then you might not test everything in the same way everytime, so you are bound to mess up and release software filled with regressions and crippling bugs. It becomes even more messy if you get other people to help you test your software, as they might not know about all the features of the software or how to use it.

When you or someone else is doing the testing and not the computer, this is called ​manual testing. The combined list of instructions and other details is called the ​Test plan. By using a Test Plan you can make the testing of your application more consistent, increasing the chances of you catching regressions before it's too late.

The Test Plan

The anatomy of a Test Plan

A test plan is made up by a few constructs:

• The user action is the feature that is being tested.
• The precondition or prerequisite is what the tester needs to do before they can properly test that particular feature.
• The steps are the step by step instructions on how to carry out the test correctly. (Use two pipes "||" to separate each step.)
• The expected results or expected outcome is what is actually ment to happen at the end of the feature test.
• Together these form a test case, which when grouped together is a test plan.

Examples

Test Cases

User Action	Precondition	Steps	Expected Results
Dragging & dropping midi files onto MidiPlayer while playing	Put two midi files that you will test somewhere convenient, like on your desktop.	Start playing the first midi file. || Drag & drop the second midi file onto the MidiPlayer window	The old song stops and the new midi song is played.
Disable and re-enable the Scope	The main window is open	Uncheck the check box marked scope || The check box is then unckecked || Click the button marked play || Stop the midi from playing || Check the scope checkbox || The checkbox is then checked || Click play	When disabled the midi plays successfully and the scope is not displayed, when re-enabled midi plays successfully and the scope is displayed.

Test Plans

You can download an example test plan here and simplified template for you to edit for your task. They are both CSV files (​comma separated values file), which is the same format that you need to submit your work as.

They can either be opened using a spreadsheet application where you just edit the cells, or you can open it in a text editor where you have to deal the formatting yourself, but which is more powerful.

On Haiku you can download the spreadsheet application SumIt from the HaikuDepot app store and the advanced text editor application Pe is currently bundled with all copies of the Haiku operating system. On Windows you can use Microsoft Excel and Microsoft Notepad, while on Mac you can use Apple Numbers and Apple TextEdit. On Linux you can use Gnumeric or Calligra Sheets and the text editors gedit or KWrite.

Tips for creating test cases

• Check out the Haiku User Guide's ​section on included applications; it often covers advanced features.
• Does the the application have any keyboard shortcuts that could be tested?
• What happens when you change the system font size?
• Can files be draged and droped onto the application in order to open them?
• Do all the buttons do what they are expected to do?
• Do the menu bar items work as intended?
• Check the ​Ubuntu qa website for a similar application to the one in your task and then look at things they test it for.
• If required, ask your mentor for the location of some demo media files to use in your test plan.
• Does the application still support the media files it is meant to?