When I'm testing, I do a lot of explicit modeling. I say explicit, because I actually draw pictures. They aren't just in my head. I have a couple of heuristics I use to know when I'm done modeling a testing problem:

1. If I can't derive explicit test cases from my model, perhaps it's not detailed enough and I need to keep working on it.


2. If I can't explain it quickly to another tester, perhaps it's too detailed and I need to abstract it a bit more to simplify it.

Sometimes we need to reframe our problems to devise better solutions, for instance when we're overloaded with work and need to take on new interests or responsibilities. I've found one useful technique is to use a 'power of 10' to help reassess my current approach. Here are some examples of how it works for me:

I imagine I'm now responsible for ten times the amount of work, with my current work limited to one tenth of my commitments, which allows me a maximum of 1/2 day per week for it. What are the most useful and important things I can do with my time to help and support my current project? Then I try to make sure that, from now on I do that work first each week. Of the remaining work, inherently it's less important so I try to pick the next most important tasks and do them next, etc. Eventually, say after 2 days per week I decide the rest of my old work is no longer useful so I don't do it. Now I have 3 days to take on new work, learn new skills, fix problems, etc.

Another use of powers of 10 is to imagine I have 10x the number of testers, machines, etc. - how would I use them to improve my testing? Generally I find I have a list of possible ideas with some idea of how much they'd help. Now I pick a few of these and implement them (possibly in the time I've freed up from the first example :)

Note: try using powers of 5 (to match one per day of the working week), 100 (e.g. test machines), etc. to help breakthrough your current mindset and challenges.

At CAST 2008, I heard Adam Goucher share a mnemonic he uses to determine what to test first when the schedule is short and he needs to test the important stuff first. I took the following notes:

• Security: the first thing to test


• Languages: internationalization


• Requirements: new features, not regression


• Measure: performance, stress, and scalability


• Existing: regression testing

You can see more on this topic on Adam's blog.

Sometimes I get stuck. I run out of test ideas. You can't tell me you've never found yourself looking blankly at the screen, clicking the same button over and over, hoping without hope that this time it will manifest the ever-coveted NullPointerException. It happens. Sometimes the well runs dry.

It can be a mix of stress, exhaustion, repetition, or a sincere inability to think of additional test ideas given what you currently know of the system. At those moments, I find that I can re-energize myself and generate new test ideas if I do two things:

1. Find coffee (what can I say, I have a problem)


2. Find a diagram (and if I can't find one, I make one)

Diagrams get my mind moving again. Sometimes when I'm looking at a screen (particularly a screen I've been looking at for the last four hours) my mind goes blank. But if I'm looking at a diagram, the ideas come back. I particularly like sequence diagrams and state diagrams, but I find that good use case diagrams and class diagrams can also do the trick. If I can't find any diagrams to get my creative juices flowing, I'll create my own. I often find creating a simple UCML diagram is enough to get me thinking about new risks and coverage again.

To sum up, my message to the serious programmer is: spend a part of your working day examining and refining your own methods. Even though programmers are always struggling to meet some future or past dead-line, methodological abstraction is a wise long term investment.

- Robert W. Floyd's 1978 ACM Turing Award Lecture

Here are some guidelines James Bach gave me for coming up with a heuristic:

1. Attempt to solve a problem.


2. Conceive of a need or desire to add structure to that attempt.
   OR
   Notice a pattern.


3. Look for a pattern in the problem you are solving.


4. Try to understand the pattern as best you can:
   
   
   
   • What’s the essence of this pattern?
   
   
   • How can I simplify this pattern?
   
   
   
   


5. Label it.


6. Try it (experiment with it).
   
   
   
   • Be a skeptic.
   
   
   • Vary your label.
   
   
   • See if you actually remember your heuristic when you need it.