Heuristics are rules of thumb or fallible methods for decision making. If you aren’t interested in such things then please consider how many decisions you make everyday without complete information. Every time you make a decision you are using a heuristic. I’ve found it helpful to think about and study the heuristics I use so I can apply them better, and make better decisions in the future. This page will outline my heuristics and may contain links to others.
Calm Before the Storm – Everything seems to be going perfectly with a person, project or task. Everything is on time, on budget, and seems to be almost too perfect. This may be a cue to investigate further. Very few things are really that perfect. That person may be hiding something from you, or code may be completed on time, but with poor quality. This heuristic has helped me catch problems before they became bigger problems.
Rule of Three – I will eventually devote a long article to this, but the rule of three seems to be an almost universal heuristic. Jerry Weinberg suggests that we should think of at least three exceptions to any rule. A former Army man told me he was taught, “… once is a happenstance, twice is a coincidence, but three times is a pattern…”. In high school I was taught to include three supporting paragraphs for the main idea, and at work I try to keep any company communication focused on three main ideas. (Please note that I provided four examples.) This heuristic has helped me give pause and really think about things before I open my mouth or make a decision. If I can’t think of three things to include then I probably haven’t thought enough.
Questions - I believe you can tell a lot by a person based on the type of questions they ask. This has been especially helpful when training and interviewing software testers. The more questions someone asks, the more likely they are to exhibit strengths of a good tester.
Team getting sick - I use the health on a software team as an indicator of team happiness. An unhappy, unmotivated, or overworked team may call off of work more. So, if I notice that people are calling in more often then I use that as a trigger to investigate further.
Technical Decisions belong to the Doers -
Automate to Cover a Risk – I’ve seen some testers try to use GUI automation to perform all of the tests that a manual tester would perform. I prefer to think of a specific risk in the system and then find the best way to automate for that risk. It keeps the testers focused on the most critical items, and reduces high maintenance, low value, GUI tests.
Summarize, but have Details – When reporting a status try to keep to focused bullet points (maybe just use three at first) but be prepared to answer questions. As a manager I was focused on getting an overall status and then probing if something interested me. Managers are not involved in the technical day-to-day details and can get bogged down with too much detail.
Be Helpful – You don’t always have to be the best or do things perfectly. But at the end of each day if you were helpful to your company, colleagues, friends, or family then it was probably a successful day.
First Order Measurements – Humans have the ability to look at something and measure the “goodness” of it. We can decide if a tree is beautiful, or a street is busy, or if an application is good. We can do these things without counting the number of good leaves, or the number of vehicles, or the number of bugs. The human “feeling” about something is a first order measurement and if very helpful, in my experience more helpful than counting things. This doesn’t mean that we don’t then need to investigate based on these first order measurements, but our context should dictate that…
Consider Context - The context-driven software testing community has it right, and I do my best to follow that philosophy in software testing, social settings, and in my marriage. It’s a rule of thumb that keeps me out of silly arguments because it forces me to follow Stephen Covey’s rule, “Seek First to Understand…”. By first truly understanding what someone means (their context) then you can avoid arguments due to semantics and get right to the heart of it all.
One Last Thing – “I just want one more chip.” Cravings are difficult to suppress, but a craving for one more test is very important for me. Before I say that I’m done testing I’ll spend a few minutes to think of what else could go wrong. At worst it just further confirms that the application is in pretty good shape, but at best it uncovers a new set of bugs that I hadn’t thought of before.
