Would Heu-risk it? Part 31: The Memory Master

Picture of a chicken holding up a card with a blue heart, while a rabbit tries to guess the card

Our very last card is, of course, a tool. Often mixed together with heuristics but darned useful if used right. First of all, rhymey timey:

“Mnemonics are awesome, now let me tell you why
They help you come up with new ideas to try
Pick one that helps you, or try something new
Important to remember: It must make sense to YOU”

So, what does it mean?

Mnemonics are memory aids that we use to make it easier to remember complicated things. My first memory of a mnemonic is from school where we used rhymes all the time to learn things like days of the month, rivers in Sweden, how to tie a shoe. In software testing there are a lot of them, SFDIPOT probably being the most well known.
SFDIPOT can be used as a model for thinking about what to test and stands for Structure, Function, Data, Integrations, Platform, Operations, Time.
Another well known one is the RCRCRC regression Testing Heuristics by Karen N. Johnson
This one deals with things to consider when deciding on what to regression test and stands for Recent, Core, Risk, Configuration, Repaired, Chronic.

Heuristics are approached we use to solve problems that are similar but not necessarily the same. Maria Kedemo did a wonderful workshop at one of my previous companies where she used opening doors as an example, which I think was brilliant.
I am sure most of us know how to open doors. We open doors all the time. We know how doors, and door handles, usually work. When we come across new types of doors and/or handles, it does not take a lot of mental effort to figure out how to open them. And if we fail the first time, we can usually figure out some ways to try, based on our mental model of doors and door handles. We can also pretty easily decide if there is a problem with a door, based on our experience. If the handle has fallen off, we know that this is a “bug”. If the lock shows the door should be open but the door is locked, we can decide that it’s a “bug”.
I think that example was amazing and all kudos to Maria for introducing it. It’s the best way I’ve come across for explaining heuristics.

I will keep this post short, because I think there is already so much written about this but what I want to add, that I don’t see that often, is that these mnemonics and heuristics need to make sense to you. There is no benefit to trying to force yourself to use someone else’s mnemonics and/or heuristics if they don’t help you. Just as models, they are not perfect and we are all individuals. And of course: Your context will be totally different to mine.
However, the concept of them is helpful so why not try to phrase one that helps you!

SFDIPOT is a good example. A lot of people use it all the time but it has never stuck with me. So I decided a while back to stop trying to force myself to use it and try to come up with one of my own instead (sometime in the future. To be continued!)

Story time

It’s hard coming up with a clear example because I think this is so ingrained in everything we (I?) do. Being good overall testers, I think we are usually very good at creating and utilizing heuristics. We can take what we learnt from one system and apply it to another.
We extend the heuristic beyond, perhaps, what most people do.

I’ve always felt learning new applications is pretty easy and I can often apply things I learned to new tech stacks, new business areas.

I do think my background as a developer helps a lot with that. I can kind of pick a system apart into pieces and find the seams. If you can identify the seams you can usually pretty quickly think of potential cracks and gaps.

The mnemonic I use most is probably CRUD, but I didn’t really think of it as a mnemonic until a while back.
CRUD stands for Create, Read, Update, Delete and honestly – isn’t that most of what systems do? It’s a model I usually build all of my questions, tasks and tests around to make sure I don’t forget something.
I also have pretty good ideas which of those are more risk prone than others (read can have a lot of potential variants, delete is risky because it’s easy to mess up chains of data, create is risky due to constraints and so forth).

My favourite mnemonic is probably a rhyme for remembering days of the week (“Trettio dagar har November, April, Juni och September. Februari 28 allen. Alla de övriga trettio-en”) but that is not very work-related 🙂

Quote of the day

“Rhyme is a mnemonic device, an aid to the memory. And some poems are themselves mnemonics, that is to say, the whole purpose of the poem is to enable us to remember some information”

James Fenton

Reading suggestions

Software testing heuristics – mind the gap! – Ministry of testing
Test Heuristics cheat sheet – Test Obsessed
Heuristic Test Strategy – Satisfice
Examples of mnemonics – Your dictionary
Software testing heuristics and mnemonics – Karen
Mnemonics and heuristics – Maria Kedemo

I also got a bunch of links from Maria that I wanted to pass on, thank you so much Maria!

Previous posts in the series

Title and linkCategory
Part 1: IntroductionNone
Part 2: Mischievous MisconceptionsTrap
Part 3: The RiftWeapon
Part 4: The FacadeTool
Part 5: The Temptress’ TrailsTrap
Part 6: AlliesWeapon
Part 7: Don’t turn backTool
Part 8: The GluttonTrap
Part 9: Beyond the borderWeapon
Part 10: Forever and neverTool
Part 11: The ShallowsTrap
Part 12: The TwinsWeapon
Part 13: The ObserverTool
Part 14: AlethephobiaTrap
Part 15: Opus interruptusWeapon
Part 16: The IllusionistTool
Part 17: Fools’ assumptionsTrap
Part 18: The UnexpectedWeapon
Part 19: Constantly ConsistentTool
Part 20: Drowning in the deepTrap
Part 21: The Hive Weapon
Part 22: The ContractTool
Part 23: The ShapeshifterTrap
Part 24: Lost in translationWeapon
Part 25: GoldilocksTool
Part 26: The InconceivableTrap
Part 27: The jugglerWeapon
Part 28: Three is the magic numberTool
Part 29: Tunnel VisionTrap
Part 30: The CorruptorWeapon
One Comment

Add a Comment