Mind maps as a testing tool bug me a lot


I use Mindmup.com for my mindmaps
I use Mindmup.com for my mindmaps

There is one thing that bugs me about mind maps as a testing tool, it really bugs me a lot.

Don’t get me wrong, I find mind maps a great collaboration tool to get ideas out of people’s heads and put them on paper. They are great for designing a test plan, a few testers can sit down, brainstorm and create a map that can be efficiently used as a complete plan.

So what bothers me so much?

This: “Why don’t we do the same exercise together with the developers before the code is written?”

Are we so obsessed with finding bugs that we cannot share our thought process and help PREVENT (yes prevent) the defects instead of catching developers out and wasting customer’s money and time?

I really hope that somebody out there will give me a valid reason why we shouldn’t shift left the mind map creation and prevent the defects instead of detecting them.

Otherwise we should start doing it now, no excuses.

Advertisements

18 thoughts on “Mind maps as a testing tool bug me a lot

    • I am 100% with you, the mind map I am referring to is pre product creation and it includes many elements of analysis. In my context we test ideas to prevent defects, software to detect them and product owners assumptions to reduce waste.

  1. Thanks for that post Augusto – it’s an important reminder,
    Though all it takes is “Just do it” 🙂
    Nothing holding us from doing that, we might need to remind System Engineers to use visualizations like MM when presenting new feature design & requirements,
    And of course, as we plan and review our tests (high level and/or detailed) we can & should use MM, and Devs should be part of that process – learning from it (hopefully its done before they wrote the code).

    But – reading the LinkedIn post header of “Can we go a step further and use mind maps more effectively?” – I was hoping for another sort of post.
    For a while now I have been saying – What’s the benefit of MM over Tree as we see in ALM tools?
    Why don’t we see MM integrated as another view type in ALMs?
    After all – MM is just another way to present a tree, while those who walk the extra mile also add some Colors & Icons to enhance visualization.
    Any ALM tree can be presented as MM towards review etc. – and use different parameters to drive several views of same tree (coloring & Icons based on Risk, Priority and more)
    While still benefiting from writing Once, in a Central place, with Most Updated version always Visible to all project members on-line.

  2. Hi Augusto,

    What are the reasons you think are preventing us from preventing defects:
    * Developers and Testers are not co-located?
    * Too expensive?
    * Management don’t believe in preventing practices?
    * Etc

    • Hi Thanh, you mention potential reasons.
      In the first option, sharing would be still possible unless we have a not co-located test team that is not involved during development but comes into play only after the fact. This last is in my opinion a bad model, and the perceived saving is a false economy.
      I disagree that this would be too expensive, collaboration creates shared knowledge and enhances artifacts, pairing in many activities is much more effective and ultimately cheaper than working in isolation.
      There are many managers that focus on resource utilization without understanding that real value is not in having people 100% occupied but an optimised flow of value (https://mysoftwarequality.wordpress.com/2014/12/03/the-resource-utilisation-paradox-on-why-less-is-more/)
      Another reason is ignorance and/or refusal to adapt and change
      Another reason is protection of revenue, some testers believe that if they help prevent defects they are then less useful.
      Not sure what else, maybe you can help me here.

  3. Personally, I despise mindmaps.
    Yes, they are a great aid when brainstorming, but the problem is that you end up with a physical artifact that is very much like a shell scripts – it has meaning only for those who created it. So you end up by thinking you could just share the mindmap and gain something.

    • Amit, I agree that sharing a mind map post creation might not be always useful, on the other hand I see it as a very effective collaboration tool when more than one person participate into its creation and gel their thoughts into it

      • As I said (or at least, thought I said) – I can accept mindmaps as a collaboration tool, or even as a personal thinking aid (not for me, but if it works for someone, why not?). I have seen, however, way too many posts of “look at my cool mindmap, isn’t it lovely and very useful? it contains *everything* I\we could come up with with regard to …”.
        In my eyes, it is becoming an alternative to writing a well structured argument. just throw a couple of words into a tool that will make it pretty and you’re done. it is this property I find myself very much against (on the other hand, I have a similar issue with Twitter, so it might be that my attitude is a bit too strict).

  4. @Gus

    1) When a tool is used in the service of testing (yes, review of a design is testing), isn’t it a testing tool?

    2) When you say “Are we so obsessed with finding bugs that we cannot share our thought process…”, who’s this “we” you’re talking about?

    3) You’re referring to “the” mind map creation as if there were only one. Who says there must necessarily be only one?

    @Amit

    4) You seem to believe that creating an artifact is a big deal. But in mind mapping, it’s the “mind” part that’s important; the “mapping”, not the map. Creating a mind map is an exercise, not a life sentence. If the map is too large or too confusing to be of help in thinking about a product or feature, or in helping in a conversation with others, that’s an interesting test result right there. This is true of any artifact; a specification, whiteboard diagram requirements document, flowchart, OR code base.

    —Michael B.

    • Hi Michael, answers in sequential order.
      1) It sure can be a testing tool, but why can’t we use it before? It would be much more effective.
      2) Testers
      3) Not sure what you mean here, but yes I am aware you can have as many maps as you want

      • When we are sitting with the developers together before the code is written, we are testing. As I said in my first reply, review of a design is testing. So the mind map is a testing tool and a reviewing tool and a design tool, and we can use it for all three purposes at the same time; and yes, that means before the developers write the code.

        Testers do (or, at least, should) share their thought processes. Testing is evaluating a product learning by learning about it through exploration and experimentation (Bach and me); gathering information with the intention of informing a decision (Weinberg); an empirical technical investigation of a product done on behalf of stakeholders (Kaner)… If that learning, that information, that investigation (and the thought processes that go into them) are not shared, then the testing is pretty much valueless. That sharing can, should, start from the beginning of the project to the end of it (and maybe after it, too).

        By the third point, I mean that you can have lots of different maps. Some at design time, some at review time, some during coding,… any time you like. If those maps are used in the service of learning or gathering information or investigating, they can be testing tools AND they’re tools for other purposes at the same time.

        Finally, to this business of “preventing defects instead of detecting them”: we never prevent defects without detecting them. I believe what you’re calling prevention is discussing and reviewing and designing and identifying defects in what people are thinking or planning or designing and addressing those defects before they get buried or get worse. I think you’re talking about preventing defects from reaching a customer; release bugs, or preventing defects from reaching a build where they’ll cost bug investigation and reporting time. I’m all for that. I think what you’re talking about is preventing a defect from growing into a full-blown tree, with branches and leaves and roots that will be hard to remove. But whether you identify it as a seedling or a seed, it’s a defect; somebody, somewhere, has an idea that turns out to be dangerous or risky or wrong. We want to prevent that idea from going farther, from getting worse; that’s good and important. But to do that, we have to detect it. So, yes, I believe it’s essential for testers (and everyone else) to focus on errors in that sense.

        You might enjoy Jerry Weinberg’s new book, Errors. It’s mostly a synthesis of stuff from earlier books. The first long reply in this interview is worth reading too, in my view. http://www.developsense.com/blog/2011/01/jerry-weinberg-interview-from-2008/

        —Michael B.

    • @Michael –
      This is true.
      An artifact is something you can share and show around – very much like scripted test cases. And, since the person sharing it originally is someone who participated in the mapping and therefore does find that artifact useful. In my environment (thankfully, not in my workplace), I am seeing those map sprout like mushrooms, so there are at least some who confuse the usefulness of the process with the resulting physical artifact.

    • @Michael – To Me the question is – What makes MM a useful tool for thinking about testing?
      In compare to a Tree for instance?
      (Should it really get so much hype within the testing community?)
      Now – MM still has its graphical advantages (Colors & Icons), but using these already require effort which might switch your mindset from the thinking process into managing the MM, and it seems that the only benefit of these are in cases where you share the MM (as said above – the artifact should not be our focus).
      So if one does prefer to use it while presenting data to others – I would hope these parts would be automated, rather than manually set – leaving writer focus on judging the content.
      I wonder if we should hope getting these graphical abilities of more coloring & icons in trees used in test management tools, will it help visualizing the coverage or just confuse us…

  5. i am in fully agreement with you,, that’s why we have a process called as External review where development and testing will sit together to share TC written,, Yes i agree,, the more earlier its shared the better will be for the project

  6. Hello

    In my opinion there are no opposition between improve the collaboration in order to prevent the bugs and have a formal quality gate with the aim of find bugs.
    We should, in a large organisation with integrated system, have the two layers:
    – improve the way of code delivery meaning think before coding in term of testability with testers involved in dev team
    – put in place a real acceptance with a strong, autonomous and relevant test team. The aim here is not to find low level bugs but accept in business point of view.
    I believe that only have the 1st layer couldn’t work in a big organisation with integrated IS and have only the 2nd is not efficient.

    BR
    Matthieu (test manager)

    • Matthieu, I believe that a full strategy will depend on the specific context. In general I believe that an independent team of testers that serves as a quality gate is very inefficient, but there might be contexts in which this is not true.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s