A little history... As I did my best to teach a tester how to write test ideas for an Agile story I found myself wondering why I found coming up with ideas and questions a fairly easy activity and why they seemed not to find it quite so easy. Practice would have had something to do with it, but I also suspected a slightly different mental model.
I went out to try and find 'other' models for generating ideas and structures quickly. The first thing I found in the library had the title "Blank Page to First Draft in 15 Minutes", authored by Phillip Khan-Panni (BPTFD). Obviously not considered a classic as Amazon lists it as currently out of print, but the reviewers seemed to like it. [amazon.com][amazon.co.uk]
In terms of preparing for presentations it offers as much as most presentation books - but can it help me generate test ideas?...
First start by examining your belief system - "Can you adequately prepare (for testing) in a few minutes?"
When I write 'test ideas' I consider what I do as 'exploring' a topic - hence the reason I picked up the presentation book in the first place.
- "Don't even think of busking it!"
When we identify sets of test ideas or high level charters we do a planning activity. So if you have any hang ups about planning then "Drop Them Now!". We can plan really quickly. We can change our mind after we have planned when we learn more. If we identify something that seems stupid then we can remove it later. If we identify something that someone else finds stupid then we get good feedback on what seems important to them and what doesn't.
If you do have any hang ups about planning quickly then write them down, then challenge them.
- "Why is it you?"
Each tester brings something unique to the planning process. They may bring a different understanding of the system. They may bring a different educational background leading to different questions. They may have different levels of technical skill so they view the system differently. Use and capitalise on your unique skills - don't think that you have to rely on 'standard' test derivation techniques. Bring your unique approach to the table.
If you don't know what you uniquely bring to the project then I suggest you start modelling what you do. Then comparing notes with what other people do on the project.
- "What is the message?"
When you sit down to write test ideas try an approach of asking questions with each one. Each 'test idea', when pursued will provide you with additional information, so identify the 'message' that you want the test idea to supply back.
e.g. "Mr Big String" approaches a text field and wants to stick in really really long strings. The information he wants to get back relates to limits - does the software have any? should it have? does the system respond well? how long can it handle? - Mr Big String knows his unique strengths and has PerlClip close at hand at all times.
Identify test ideas that justify the time you will spend exploring them.
- "Who is the audience?"
Who will care about your information?
Do your test ideas represent things that people care to receive information about?
Identify 'stakeholders' for the 'thing' under test acts as a useful tool for looking at the 'thing' in different ways and getting new ideas about what questions seem important to ask of it. see also [soap opera testing]
Identify people on the team who want information about this 'thing' that you will subject to scrutiny - what information do they want.
What about you? What information do you want? What do you 'doubt' about this 'thing'?
Do you even know what stakeholders this test idea has relevance for? (do you consider yourself a stakeholder of testing?)
What approach do you plan to adopt? How will you do the things you want to do? A little up front thinking might identify some environmental constraints that you might need to spend time on so they don't stop you. You might also identify some unusual approaches that could help you.
e.g. Unfortunately I can't remember the complete details of this incident. On an early version of the Ruby/Watir course that Brian Marick and Brett Petichord conducted at one of the Star conferences. My pair and I wrote a little script to churn out a whole bunch of random commands into the system - we didn't expect to find any 'positive' responses to our 'test' but as the text scrolled up the screen we saw the system respond positively to some input - our random text named a 'hidden' command that had been 'removed' in an earlier version of the system. In the real world - that could have counted as a possible security bug, or an unfinished deprecated feature removal.
- "identify a single message that will bring about some change in the thinking, attitude or behaviour of your audience"
Can the test ideas that you generate have that degree of power? How far can your test ideas push the system?
Go on, get a little evil when you have ideas.
Identify provocative test ideas.
- "You've got to have a Nangle" - quoting P.G. Wodehouse
Do you have a unique angle?
Do your test ideas cover the same ground?
Do you plan to repeat testing done at the unit level? Have you checked?
Do you know what type of data you want to use? How different to previously used data can it become?
- "The Importance of a sexy title"
Make the test ideas short and punchy. You don't want to write down everything you could think of for each idea, but you could try giving it a short expressive description that lets you know what you thought then and prompts new thoughts as you step up to explore.
e.g instead of "enter big strings, check that the system test that the system handles a big string of >30000000 chars"
"Mr Big String pastes in Atlas Shrugged"?
yeah, I know - you can do better than that... good.
- "How important is it that you speak? : How will it benefit them? What would be the consequence of not going along with you? Will it matter if you never gave the speech or presentation?"
How confident do you feel that you have identified the priorities appropriately. Double check the ideas.
You know when you have targeted risks because they spool out in answer to... "If you didn't do this what might happen?"
- "Answer the 'so what?' questions about your facts"
If you have done the above thought processes then you can probably quite easily justify your test ideas and sell them to anyone that might care to ask you what you want to do.
You might want to ask yourself the 'so what' question anyway - just to make sure that you have comfortably thought out the scope of what you want to do.
"Mining your brain for usable content:
- What is your core message?
- List all your ideas
- Use short sentences
- No Editing
- don't dwell on any one idea
- keep going
- If you dry up - ask some questions - use an idea as a spring point"
So in summary - I did find hints of a few techniques and approaches that I use when constructing test ideas:
- stakeholder analysis
- risk identification
- punchy statements of intent
- provocative reviews
- early approach planning
...and I found this a fun exercise. So all ends well for me.
PS - thanks go to James Lyndsay for providing the character of Mr Big String in a class exercise a few years ago.