When analyzing a lot of information, it’s always a challenge to retain things in memory. In order to facilitate this process, mnemonics were invented — simple mechanisms of tweaking your brain to memorize and later recall some sequence of actions, events, or other data. I’d also like to show you how they can improve your software testing process.
Typically, mnemonics are abbreviations, but they can also be individual words, phrases, sentences, or even verses.
Below are examples of commonly used mnemonics:
- ROYGBIV (or Roy G. Biv) is an abbreviation describing a list of primary colors of the visible spectrum or rainbow: Red, Orange, Yellow, Green, Blue, Indigo, and Violet. An alternate mnemonic for this would be a phase like “Richard Of York Gave Battle In Vain”.
- Some non-native speakers find it difficult to remember correct spelling for some words. For example, which one is correct: “neccessary”, “neccesary”, or “necessary”? We could use a text mnemonic like Not Every Cat Eats Sardines (Some Are Really Yummy), but a visual mnemonic looks even better!
- You probably know that in British and American English some words are spelled differently. For example, the word “gray”: in Britain it is “grey”, but in the United States it is “gray”. Using a mnemonic, remembering which is which is easy: in America it’s “grAy”, but in England it’s “grEy”.
- Mnemonics are often used on phone keypads: calling 1-800-TRAILHEAD means dialing 1-800-872454323, as it is easier to memorize a meaningful word rather than a long sequence of numbers.
- “In 1492, Columbus sailed the ocean blue” is a good example of rhymed mnemonic to remember the year, in which Columbus started his journey to discover New World.
Mnemonics in Software Testing
Mnemonics are used in various fields of human activity, and software testing is of no exception. Using software testing technique called “error guessing”, performing exploratory testing, or just writing checklists — mnemonics can help us with all this, and in this article I will tell you about the most interesting and useful ones.
This mnemonic (pronounced as “San Francisco Depot”, and also known as SFDiPOT (or just SFDPO originally), was proposed by American software tester and consultant James Bach, and is one of the most well-known and versatile ones. It’s often used for testing on mobile devices, and stands for Structure, Functions, Data, Platform, Operations, Time.
S – Structure
What happens when we run and update our application or OS firmware on the device?
F – Functions
What are our application’s main functions and how do they interact with the device’s functions?
D – Data
What kind of data does our application work with? What data is accessed and stored on the device?
P – Platform
What are our application’s dependencies on the device OS or its browser type/version.
O – Operations
How does our application operate in airplane mode or under unstable or missing Wi-Fi signal?
T – Time
How does time affect our application? How does the application work in different time zones?
Created by software testing consultant Karen N. Johnson, the mnemonic is useful for planning and performing regression testing, and stands for Recent, Core, Risk, Configuration, Repaired, Chronic.
R – Recent
What was recently changed in our application?
Recent changes are a possible cause of defects. Changes include both new features and fixes to existing functionality.
C – Core
Applications have a small subset of functions called core functionality, so we focus on those.
We ignore all the “bells and whistles” and try to get to the essence of our application. Most likely it won’t be an overly long list of features. If testing seems like a huge space with no end in sight, defining key functionality will help us focus. So, instead of thinking about boundary values, pick the most typical ones. And instead of wading through secret paths, walk down the middle of the road taking the main paths (e.g. “happy path”).
R – Risk
Applications usually have areas that are designated as high-risk.
For example, think about the features that depend on other services/components to be up and running or directly related to financial calculations. Just like with the list of core functions, this list of high-risky areas should be short.
C – Configuration
Code that depends on environment parameters is configuration-sensitive and is considered more vulnerable.
Keeping such application features in mind helps us decide whether to retest specific functionality and in which environment.
R – Repaired
How often should fixes be reverified?
If a defect is fixed and the fix is verified, should we continue verifying it again and again in future releases? What are criteria for us to say that a fix has been verified enough times that it should no longer be verified again?
C – Chronic
We, humans, have some weaknesses, so do our applications.
One of the reasons why working with one application for a long time is so good is getting a deeper understanding of its problems. The longer we work with our application, the more we know where the problems have been, where they are now, and where to expect them in the future. Does our application have areas where problems often arise? Bugs cluster, so wouldn’t it be useful to pay more attention to those areas and run some more regression on them? We can also use defect statistics from our bug tracker to identify weak areas that have had the most problems in the past.
With this mnemonic, the famous author and software testing expert Cem Kaner shows how to compose an almost perfect defect report. It stands for Replicate, Isolate, Maximize, Generalize, Externalize, And…
R – Replicate
Find the conditions under which the defect is easily reproduced at will. Phrases like “it seems”, “it looks like”, or “sometimes” don’t look good in a professional defect report.
I – Isolate
Reduce the number of reproduction steps to a minimum. We need to know exactly what is causing the defect.
M – Maximize
Demonstrate how much harm the defect can cause, how severe it is. For example, users may be just confused and annoyed by encountering it, or application data may be damaged irreversibly.
G – Generalize
Find out where and how else the defect can cause problems — “uncorner” the corner cases. Try to find other, broader ranges, in which the defect can be reproduced.
E – Externalize
Make sure that all the relevant stakeholders (developers, managers, customer representatives etc.) have heard about the bug and understand how it affects the application.
A – And…
…be neutral, be unbiased, don’t look for someone to blame. A defect report should be a piece of information devoid of emotional coloring and judgements.
There are many other mnemonics in the software testing world for different occasions. Learn and apply them, and create your own to make testing more robust and creative! Here are a few topics for further reading on the subject, if you’d like: