01219245/manual testing

We will develop a set of test cases for important features for your game and your friends' games. Then, you will test your friends' games and give your friends feedback.

Feature list

First, start by listing a set of important features. These are MUST-HAVE features. The game is playable only it can perform all of these features. You, as a tester, and your friend, as a developer, have to agree on this list of features.

For example, the list for the Gozilla/Cannon game is as follows:

• The game shows that Gozilla on the screen at the position where it can be hit by the cannon balls.
• The player should be able to adjust the cannon's angle.
• The player can fire the cannon balls.
• The cannon ball can hit the Gozilla.
• The player can adjust the initial speed for the cannon balls.
• After the Gozilla is hit, new one appears at a random position.
• If the player fire 5 cannon balls and still miss the Gozilla, the game is over.

Practice: Make a pair, work on the feature list. Put them on a google doc.

Create a Google Doc Spreadsheet document and put these features in one of the sheet.

Test cases

For each of the feature in the list, we shall think about how to verify that the software actually delivers that functionality. The best way to demonstrate that is to test it. To test the software, you can just sit at the computer with the software and then play with it: this is called exploratory testing. Today, we will focus more on a traditional type of software testing; people sometimes refer to this is scripted testing.

We will look at each feature and think about the steps we have to perform to demonstrate that the feature is working and write those steps down. The activity you are doing is called test case design. Then, someone (hopefully, you) will take the test cases and perform the testing.

Usually, for each feature we might be able come up with two types of test cases:

• Happy test case: this type of test cases demonstrate the successful situation.
• Unhappy test case: this type of test cases demonstrate the exceptional situations, i.e., when things do not go according to the plan.

For each of the features, try to come up with happy test cases (a few would be great) and at least one unhappy test case.

You should write down the test case into the following template (see spreadsheet example at the end):

Feature No: ________________
Test case No: ______________
Description/Goal: ______________________
Steps:  
  1. ________________
  2. ________________
  3. ________________
Expected result: __________________

You need to keep feature numbers and test case numbers so that you can refer to it later.

Practice: On the google spreadsheet, create a new sheet called "Test cases", and put the test cases in that sheet.

Testing result

After you design all the test cases, you (the tester) and your friend (the developer) should agree on the test cases. Then it's time to perform the testing.

Practice: You start with the test case list. For each test case, perform the steps as described in the test case. If the actual result is as expected, that test case passes, otherwise it fails. Put this testing result on a new sheet on the Google document.

For the failed test cases, you should put enough information so that the developer can reproduce the failure. Otherwise, the developer will not be able to fix these problems.