(One of) The most important question in testing

.. is not about the testing itself, but:

"What are you going to do about the information that testing will provide you with ?"

This is the kind of question that really shoves lots of stakeholders out of their comfort zone. I've seen more than one with flickering eyebrows, when I've asked this question.
I think, with such reactions, that this is truly an important question to ask:

• If there's no answer to this question, is the testing we do going to be useful ? - to anyone ?
• If there is one answer to this question, we might forget to debate it to figure whether it's the right answer (one could be reminded of Jerry Weinberg's Rule of Three here..)
• If there are more answers, they are bound to be in conflict with each other. Which are more important for now ? - and later ? (oh yes, priorities do change over time ;-)

You get the picture.. we are in trouble, regardless.

I find this question to be very valuable to ask, though. It gives some insight into why testers are called onboard a project. It might be, that a project manager just realised that the project manual called for testing to be done (in which case the project manager would probably be surprised and perhaps even angry when you present her/him with the bug list after testing... this was supposed to be the last activity in the project, right ?).  Or that a customer have huge problems with a delivery and wants some input to throw in the face of the developers.  Or that the scrum master needs to get his demos to actually not crash - or wants to feed his team with tasks that stabilize the code.

Testing comes in multiple varieties - so does the usage of test results.
The best advice I can give you is: ask the question and debate the answer.

In a way, this is where testing really starts...

Organizing test ideas with mind maps

I forgot when I started to draw my first mind maps.
Like I'm sure many others do, I'm thinking slightly chaotic, in the sense, that I get inspiration and ideas after I finished something.
Mind maps are, as far as I know, created for that kind of thinking. So - if you're not one of those rare and rather strange persons who thinks everything sequentially and forward, you'd benefit from it too.

My preference tool is paper and pencil. Yes, I'm bloody old fashioned, but that always works and batteries don't wear out.

However, sometimes it's practical to have stuff on a computer and I've been using FreeMind for years. It's free, it's easy to use and though it's got its fair amount of really hilarious bugs, it's stable and reliable.

So - Paul Carvalho inspired me to write about how I use FreeMind to organise test ideas. I can't show you examples from real life, as they would both be way too big to show and I guess my clients would mind if I map their business (pun intended...).

Of course I would never reveal that, but I am willing to reveal a mockup example to show how I do it.
Here's an example we all know: Google. I only used the front page and followed a few links.

You may recognize that I 'factored' the front page. We all know it as a simple text field and a search button. Most of us remember that there's also an 'I feel lucky'-button, that we only use when we're bored. But in fact there's quite a lot of other features, and they are a bit more advanced than it looks like. For instance the redirection function that shows you a localized front page.
Take a look at the real thing and compare with my little mind map here.

Factoring is a skill of it's own, I learned it from James Bach. Factoring is really about finding 'dimensions' to test. Here I just put in the functions I found, but I did make a note that there's performance in a search operation. I put it in and maybe I want to later expand that node.

Notice I reused the response time sub-tree for the advanced search as well. Is that good organizing ? Well, it's okay for a preliminary stage. But later - if we get to reuse it a lot, it's better to move it out among the common elements or something and simply refer to it. The good thing is that there are no rules. Whatever works for you - well, it works for you.

One note of warning though: if you fall into the same trap as PM's do when they repeat a block of activities in their plan - you'll get lost. Don't do that. I find that it's mostly not only convenient but also sufficient that you realise that something is repeating. There's little value in documenting everything. The real value comes from you having learned about the repetition.

So - start it up. Extend and expand as you get more information and inspiration. Extend and reuse by referring. Use icons to add some meaning or overview. Ask questions (very easy this way because you always ask the question in context of a node).

I can test directly from this and extend it while I do so. I put in ideas, functions and non-functions to look out for. A map of the system.
I can mark out branches and sub branches and put them on charters. I can readily show what works and where the problems (bugs) are. I can also show what isn't tested yet.

In short - I can communicate this and keep a great overview.

You should try it too.
  
Please let me know what you think.