What would you change and/or add to the Test Heuristics Cheat Sheet?

I don’t think it’s possible for me to count the number of times I’ve used Elisabeth Hendrickson’s incredible Test Heuristics Cheat Sheet.

It’s so helpful, particularly when planning some exploratory testing or if my brain just gets stuck mid-test. Pretty much every time I’ll see a word that triggers at least one test idea. My test efforts were saved again!

So when @richard_club asked if I’d be up for revisiting the cheat sheet to create an updated version I jumped at the opportunity! And Elisabeth has kindly endorsed this exercise. :smiley:

Here’s the plan:

  1. Review the existing cheat sheet
  2. Work with our community to explore adding new and useful (or missing) heuristics
  3. Get sign off from Elisabeth
  4. Design and publish a MoT branded version to share with the world
  5. ???
  6. Profit /s

Would you mind taking a look at the following Google Doc? I’ve moved the existing version into a Google Doc to help consume the information in a different way. Plus I’ve added some useful heuristics that don’t exist in the original. You can see them in the “Ideas for inclusion in an updated version of a Test Heuristic Cheat Sheet” section towards the end of the document.

  • What do you think?
  • What’s missing?
  • What would you add?
  • What heuristic/s have you created that you’d like to add?
  • How might you group the information on a new cheat sheet?
  • What else might we consider to create a new version that is at least as useful as the original, that takes it to the next level for years to come?

Thanks for your thoughts, ideas, and help!


One of the big heuristics I use is my own individuality and individualism. “Does this work for me”?


Thanks, Callum. Love it! I’ve added it to the doc.

Plus it also reminded me to find a way to explicitly call out the use of “personas”.


One persona heuristic I use in dungeons and dragons is SEVEN DWARVES! Is my persona (NPC) - sleepy, happy, grumpy, bashful, dopey, doc (smart), sneezy (sick)?


Something that comes up to my mind.
Extending the Date and Time section with an internationalization aspect.
dd.mm.yyyy vs. mm/dd/yyyy for dates.
And am/pm vs. 24:00 hours format for times.
I had recently very interesting discoveries in a software under test where anything was allowed.


Should a section for heuristics regarding the testing APIs be added, to accompany web tests? To me, that’s one of the big additions since when this (most excellent) cheat sheet was first released.
(willing to offer some ideas if there is agreement on the addition)


Oh when I’m testing an API I tend to use:

  • CRUD
  • Naughty Strings

Fantastic, @cakehurstryan! That reminds me of @cassandrahl’s excellent talk: Mis)Using Personas with the Seven Dwarfs. I’ve added a reference to the Google Doc.

Great idea, @andreajensen. Thanks for sharing! I’ve added your ideas to the “Time and Date” section.

I like your idea, @davadora – find a way to share heuristics that help testing APIs that are only relevant to that context. At this stage, I’m open to exploring what’s possible so if it works for you to share some examples here, please do go for it.


I don’t know if this fits into this (or if it’s already there and I can’t see it) but pressing a submit button multiple times?

1 Like

Nice idea, thanks for sharing @dsherwood.

Perhaps combining “Flood” and “Constraints” might infer this - yet that’s not super explicit.

I’ve added the following to “Flood”:

e.g. making/selecting a submit request/button multiple times

Been thinking about this for a few days ruminating whether to suggest a new section or add to what is there. Finally, I think a new section would highlight better. I’m sure this can be refined or added to etc.

Under Web Tests - new section “Accessibility / A11y”

Contents of section:
Navigation; Skip to link (first tab); No traps (menus / subsections); visible focus indicator; use all functionality; pop ups have focus, can be dismissed
Links (descriptive) ; Alt-text (descriptive or decorative is hidden); Form input labels; Main elements (only one) Country and language defined; plain language used;
Capitals in #; No all capitals text; No justified text; Zoom to 200%; Gender neutral; acronyms explained; clear instructions; Good contrast; More than just colour to indicate success e.g. green tick

Testing Wisdom

  • I am not all humans, not everyone does things like I do

Seen and heard: For everything you can see, is it announced by a screen reader? For everything you hear, can it be read (transcript, subtitles, captions, audio descriptions)


Wow, @adystokes – you’ve just officially levelled up the Test Heuristics Cheat Sheet. Thank you for sharing all your ideas. Absolutely brilliant!

I’ve added them to the google doc.

1 Like

Oh yes some Accessibility ideas would be great.
I just wonder, if that needs a reference to Web Tests.
My own testing context is a desktop app. Which needs care about accessibility aspects too. Like contrast, keyboard navigation, etc.


Good point Andrea, web tests seemed the best fit but they mostly apply to mobile and / or apps too. E.g. keyboard becomes swipes on a touch screen.

1 Like

Thanks to everyone who has contributed to this thread. Amazing! The work-in-progress document has really taken shape.

Is there anything else you feel is missing or could do with some clarification?

I’ll intend to move this forward w/b 6th September 2021. The next steps are:

  1. Experiment with grouping the content in various ways
  2. Share a draft (undesigned) version with Elisabeth Hendrickson, for her feedback
  3. Design and publish a MoT branded version to share with the world.
1 Like