Imagine you are coding a game where the player needs to pick up the red key, so they can open the red door.

When the code is ready, you’ll want to test it. You might try picking up the red key, then go to the red door and see if it opens. It does! Yay, it’s working – or is it?

When you test everything going right, this is called testing the happy path. But it’s also important to test the other paths. For example:

What if you try to open the door, but without the key? The door should stay closed.
What if you try to walk through the door when it is closed? You should not get past.
What if you pick up the blue key, and try to open the red door? It should not open.

Those are ideas for a game. On a website, there are also different paths to test:

What if someone tries to log in, but their password is wrong?
What if someone bids on TradeMe, but someone else already made a higher bid?
What if someone clicks ‘Send’ on an email, but they forgot to say who the email was to?

It’s really important that the program knows what to do when unexpected things happen. To be a great software tester, you need to think about all the possibilities – not just the happy path!