A Practical Testing Strategy
Although testing may seem simple, most people find it stressful.
Don’t panic!
Here are some strategies that will help you get started.
There are two stages of writing tests:
Deciding which features or functionalities to test.
Choosing which test cases to implement.
Which Features to Test
It’s not practicable to test everything so you should prioritize features to test based on the following conditions:
Recency: Write tests for new features, new areas of code, new functionality, or features that have been recently repaired, refactored, or modified.
Core: Test the essential functions that must continue to work for your product to be useful i.e. Your Unique Selling Proposition.
Risk: Test areas of your application that pose more risk. Examples include areas that are useful to customers, but not regularly used by the development team or parts that use third-party code that you don’t quite trust.
Problematic areas: Test functionality that frequently breaks.
Expertise: Test features or algorithms that are understood by a limited subset of people. This is to prevent The Bus Factor 1
Which Test Cases to Implement
Always start with a non-trivial happy path test case, then look at test cases that represent:
interesting input
interesting output
interesting starting state
interesting ending state
interesting instates
All possible error states
Real-World Example: Samankwe wants to implement a simple banking software that allows customers to deposit money into their accounts, withdraw money, make transfers to other users, etc.
You can ask these questions to generate possible test cases you can implement in your system:
Interesting input:
“What happens if a numerical value higher than the maximum value is entered into the system?”
“What happens if you enter a string where an integer is expected?”
“What happens if you enter a negative integer as the deposit figure?”
“What happens if you enter zero as the deposit figure?”
“What happens if you enter a blank string, a single character string, or a really long string as the recipient’s name?”
Interesting output, starting and ending states:
“What happens if the account balance figure of a customer goes below zero?”
“What happens if the account balance figure goes above the maximum system allowed figure?”
Error Conditions
“Are there expected exceptions?”
“Do we throw an exception on unexpected inputs i.e. Strings for integers and vice versa?
These few questions can generate ideas for loads of test cases that can robustly test a feature, thereby creating a test suite with decent coverage.
If you have other practical strategies for writing tests, do let me know :)
References
Test & Code in Python - Brian Okken (Episode 150)