Until now you’ve tested simple applications. You learned how to test that data was entered and if it was possible to check the data, you tested whether it was Normal, Extreme or Exceptional.
But what do you test when the application gets more complex?
Test for things that should work
In an application:
- Do buttons or links load the correct resource or perform the right action?
- Does all the media load? Images, audio or video etc.
- Features. If the application has any features such as drag-and-drop or responsive design, check each one of those works when it should.
- Layout. Does the application look correct?
In a game:
- Check inputs. Does a character perform the right action when a button is pressed?
- Check interactions. Does a character lose/gain health or a score when an object collides with them?
- Check the interface. Does the UI update to reflect the change when something happens to the character?
- Assets loaded. Does the game look right?
- Win/lose conditions. When does the game finish?
Test for things that shouldn’t work
In an application:
- For inputs. Check that the data is handled correctly. Only want a number? Tell the user about their mistake if they enter something else.
- Double, single or hold clicks. Does the application break if the user performs the wrong type of input on a resource? Double click a single click button, what happens?
In a game:
- Test the boundaries. Can a player escape the level you built in a way you don’t intend?
- Multiple inputs. Does the game only allow a single jump? What happens if someone jumps mid jump?
Break complex tasks into smaller pieces
You can break the application into smaller tasks and test after implementing each of those. Then repeat all the task tests on the final application.
For example in a game you could test:
- Player movement
- Level design + check for escaping boundaries
- Object pickups + UI
- Enemy behaviour
- Enemy interactions + UI
- Win / lose conditions
Document, document, document
Whatever you do, document the result.
- Create a table.
- Add a date and time, and test number.
- Record what was tested and what was expected to happen.
- Record what actually happened. If it doesn’t match what was expected then it is an error.
- If an error is found, write what you will do to fix it.
If the solution to the problem is apparent then write what you intend to do to fix it.
If the solution isn’t apparent, then record what you think you will need to do to investigate the error. This could be things like going through a specific part of the code because you know that deals with the area in which the error happened, or it could be repeating the steps to create the error until you have more information about when it fails.
Whether it’s part of the FA course or the workplace, documentation is an important part that needs to be done.
