The earlier testing takes place during development, the sooner bugs can be caught and resolved; this means less time and money wasted on back and forth, and therefore a faster delivery! Sadly exhaustive testing is impossible, so test plans form a vital backbone in ensuring test coverage is robust and comprehensive to mitigate any issues falling through the cracks.
During testing, it is tempting to only focus on The Happy Path; checking that the product functions as it was intended to. You enter “1+1” into a calculator and you get “2” - victory! But only testing this can negatively impact your system and, subsequently, the end user.
At Gibe, our end goal is that our websites work, look good, and that the end user has a great time using them. In order to achieve this core tenet, we have got to assume the worst and consider all that could go wrong.
But what could go wrong?
For example; the testing of an Automated Teller Machine (your everyday ATM).
The Happy Path
- The user inserts their bank card, enters correct PIN, selects the Cash Withdrawal service, retrieves cash amount requested and their card is returned
The Path to Happiness
Potential system problems;
- What if the system displays incorrect information?
- What if the system dispenses the incorrect amount of money requested?
- What if the system sends a different PIN to what was entered to the bank?
- What if the system withdraws money from the previous user’s account instead?
Potential external problems;
- What if the user enters the incorrect PIN?
- What if the user inserts their card upside down?
- What if the user has no money in their bank account?
- What if the machine has no money to give?
- What if the machine only dispenses ice cream?
Negative Testing
A testing method designed to cover the potential problems listed above, is Negative Testing. Other titles for this include Sad Path Testing or Exception Path Testing.
This involves entering “negative inputs” into the system i.e. data that it was not functionally built for. Developing a system that can handle unexpected conditions can prevent it from crashing, having slowed performance speed, or showing the user incomprehensible error messages.
With error handling put in place, users will have the tools before them to understand and distinguish when they have used a system incorrectly, versus seeing a genuine bug.
Risk Analysis
As mentioned, testing cannot be exhaustive, so comprehensive test plans are the ideal way to develop a reasonable amount of confidence when delivering a product.
Finding your biggest, testable risks is the best you can do - because let’s face it, what are the odds the ATM is actually going to dispense bubblegum ice-cream?
Step 1. Identify and list potential risks
Step 2. Prioritise the risks by assigning a number to each one; consider the Likelihood versus the Impact
Step 3. Choose test coverage that everyone in the team is happy with e.g. “All risks assigned priority 5, 4 and 3 will be tested."
Most important thing to consider = the end user
After testing the functionality of a system, usability becomes imperative! User Experience Testing helps measure how easily your system can be used and reveals what could be confusing. Typically the tests you create are completed by the intended users themselves; however if that is not a viable option, there are other routes you can take: test it yourself with the user in mind, or ask another tester, who is not close to the project, to give the User Interface (UI) a whirl. UI is all about what feels good to use - it is subjective; never assume and always ask questions.
The Happy Path is a straight line; where assumptions and wishful thinking guides the way. Let’s hope the user is holding their map the right way up! Conversely, The Path to Happiness is like a tree; where each step and decision the end user makes stems another branch, another leaf, another outcome.
