When you work with someone for a long period of time, you start to develop a shorthand for communication. Similarly, many of us have found that we leverage a lot of the same heuristics and mnemonics for communicating how we're thinking about the problem and where we're at with our work. This can become incredibly powerful as a means of saving time during documentation and verbal communication.

If your team regularly uses mnemonics like FIBLOTS, MCOASTER, SFDPOTS, HICCUPPS or SLIME then you can in many situations save yourself some verbiage and just reference those mnemonics or heuristics. If you find you don't have one for a process or technique you often practice - then CREATE ONE! And share it. For some idea of the mnemonics out there, check out this list curated by Lynn McKee.

(How can you not freaking love a mnemonic called SLIME?)

This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.

Today's tip is a content pointer.

Testing heuristics, tricks, and oracles, packed into mnemonics, on the reference page created and maintained by Lynn McKee.

Rick Grey brought the following to my attention as a Quick Testing Tip re-post candidate. It comes from Rikard Edgren over on thoughts from the test eye. Rikard takes something intuitive and builds a very direct heuristic around it in the form of a decision tree.

Today's tip comes from Santhosh Tuppad. In his blog post "Password – Flaws / Risks / Design suggestions and more" Santhosh demonstrates the power of heuristic-based testing approach combined with tool-assisted tricks.

What you'll find is a friendly walk-through, comprehensive test and UX report, references for further learning, and "is there a problem"  sample questions, - all in one. 

A must read.

With an N-tier applications testers may have to go under the Web presentation layer. For example, that could be a configuration program running on Windows Desktop. Or you may have to work with UNIX programs, directly or through a terminal emulator program. Some UNIX programs are simply called from the command line. Some other may have a sophisticated user interface, with "windows", "menus", "pop-up dialogs", and keyboard shortcuts. Today's tip is about the latter.

Track the "life span" of keyboard shortcuts to see if they are enabled/disabled on timely manner. Because, if they're not, you'll be able to bring a program into a really weird state.

As for Windows Desktop applications, track if keyboard shortcuts are defined consistently across different modules, and do not override standard meanings. That is, if "Quick Save" command is "Ctrl-S" in one module, it should not be "Alt-S" in another.