Mind2Tests - Defining your mind-map


  1. Projects
  2. Requirements specification
  3. Tests suites
  4. Test cases
  5. Test steps
  6. Describing the specifications or the suites



To be accurately converted, your mind-maps have to comply to few specific rules. These rules have to be kept in mind during or after your brainstorming sessions when you reorganize all collected ideas.

Have a look on provided samples (stored in the installation folder). They illustrate what can be done with a mind map.




A project is the central topic/node of your map. This may represent a real development projet, a sprint or just a point you want to work about, like a specific new feature for example. Around this central topic, you define your requirement specifications or test suites. Each requirement specification or test suites HAS TO be placed in a cloud/boundary.

Depending on the capabilities of the test converter, you can save the projet as a whole, in a single file, and/or its requirement specifications / test suites.



Requirement specifications:

The mind-map for requirements is naturally organized around a central topic which represents the project, the product or the sprint for SCRUM aficiodanos. The requirement specification HAS TO be placed in a cloud/boundary to be recognized by the converters. Each sub-topic then represents a requirement, a feature, a use case…

The example at the right shows a requirement specification "User Interface"  composed of 3 requirements.

The level of nodes after the requirement represents the description of the requirement. All these nodes will be concatenated in the requirement description. In the example, you can see that the 2nd requirement "The application can be dragged" is described by 3 sub nodes, that will be converted to 3 sentences in the description property.

Other requirement specifications can be also nested as shown below:

This allows you define different levels and a convenient organisation of your requirements.

Each child requirement specification HAS TO be placed in a boundary as well. If not, it will be converted to a single requirement. In our example, the specification "Specification with child specifications" has 2 child specifications and 3 single requirements.



Tests suites:

Tests suites are sub-topics around the central topic, representing a test project or a test repository that you need to define. A tests suite can also be nested within another tests suite. The tests suite contains the tests you need to import into your test management tool.

A tests suite can be empty but it is expected it contains at leat 1 test case.

A test suite HAS TO be placed in a cloud/boundary to be recognized by the converters. In the exemple, the node "Options" is a test suite and contains 5 test cases.

As a test suite can be nested in a parent test suite, you are free to define different levels and a convenient organization of your tests. The child test suites HAS TO be placed into a cloud/boundary. If not, the test suite will be converted to a single test case.



Test cases:

Test cases are sub nodes of a test suite. The structure of the test nodes depends directly on the Test Structure option which defines the corresponding test properties according to the node order. You must set the Test Structure option to reflect the capabilities of your test management tool AND your personal preference. It must be comfortable for you while working on mind-map.

Check the example below, considering that the Test Structure option defines the following order:

  1. description
  2. stepsList
  3. postconditions
  4. preconditions

The "Setting Always on top" test case has 3 nodes that will be converted respectively to the descriptionstepsLists and postconditions properties. As there is no 4th node, the property preconditions won’t be used. This example is adapted to TestLink 1.8x.

Each node/property can contain as many sub-nodes as you want. These sub-nodes will be processed by the test converter according to its specific rules. But you should consider that

  • for a text property (descriptionpreconditionspostconditions): all sub-nodes will be concatenated to a single text block,
  • for steps, each node represents a single step.
  • if a node is blank, its coresponding property will be null.
    • In the previous example, the "Setting Always on top" test case could have been defined without steps by placing a second node with no caption.



Test steps:

Test steps are SUB-nodes. They can, at their turn, contain sub-nodes representing the step expected results. You can define as many node/expected results as you need. The "expected results" property is a text property, so all nodes will be concatenated to a single text block.

In the example below:

  • the step "Click the options button" has 1 expected result in 1 node.
  • the step "Close the options" has 2 expected results each in one node. 




How to describe the specification/suite it-self ?

Add a note to the specification node. It will be converted as the specification description.




Flattr this