preload

Weekend Testing: Mindmapping

Posted by Albert Gareev on Aug 20, 2011 | Categories: Mind MapsWTAmericas

In this post I’m sharing our up to date experience mindmapping team-based exploratory testing as well as stating some expectations that a mindmapping product should meet to fulfill our needs.

Structure

As you can see, GUI part of the structure is the most developed here. Mapping is pretty obvious.
However, we’ve identified the following problems.

  • What if GUI is structured and displayed differently, based on the user roles, account permissions, etc?
  • What if GUI is structured and displayed differently because the same user can customize it?
  • What if GUI is structured and displayed differently, depending on the platform?
  • What if GUI is structured and displayed differently, depending on the operations user might perform?

Mapping all the possible states on the same canvas makes no sense. And cross-linking all the possible dependencies on the same canvas makes the map too busy.

Function

Functions is another hierarchy that is fairly easy to map. However, the typical questions you might face are the following.

  • What if two or more functions reuse the same subfunction?
  • How do you link functions to operations?
  • How do you link data to functions?

Time

The challenge for “Time” section is that any observations are highly context-sensitive. Saying like “it takes 3 seconds to execute regex” has no meaning. Even if you’d make it “the regex” with a hard-coded sample, there are still other dependencies, platform, to say the least.
We think, leaving this area as a set of questions (where one can link observations) is better choice.

Platform, Operation, and Data

Platform might affect everything, from Structure to Functions.
Operations involve using Functions.
Data can be categorized by type; samples can be given in the context of a function.


When looking at the overall map you’re probably wondering – where do value goes? where are the claims? where are the risks? Those are the questions we identified but still not sure how to map. The main challenge in mindmapping approach is in the simplicity of a mind map. The actual process and product have far more connections, the connections are dynamic, and variety of the information is beyond formalization. As so, we set the goal of keeping documented the reasonable and understandable part of knowledge – charters, session logs, bug reports, and summary reports. We believe that any participant who missed one or few sessions within the project will have a guiding structure to catch up, but will have to do exploration on his/her own to ‘load’ the process map into the mind.
We also think that as the project goes, all the mindmaps connected will form a meta-map, a 3D mindmap, storing the project knowledge.


Appendix – What mindmap application is needed to provide

Real-time mapping – viewable by the all participants right as it is being created.

Customizable Access Control. View only, View/Copy, Edit. Ideally, with back-ups and versioning.

Export. Image, PDF, and so.

Linking mindmaps to the mindmap nodes. Either in a “floating node” fashion or as a multi-tab document. Better – both ways.

Attachable content. Notes, text files, data tables and video files.

Custom markers.

Tags. With abilities to arrange by tag and search by tag.


Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.