5 Important Diagrams That Testers Need to Learn How to Use

Without visual aids, the early history, basic facts, and evolution of language would not have been sufficiently recorded or understood.

Even in a world with advanced and refined forms of writing and communication, diagrams have a unique role.

In the tech industry, our diagrams carry a significant weight.

The following are some key examples of diagrams that testers often encounter and how they use them.

 5 Diagrams That Testers Should Become Familiar With

 

Let’s start.

#1) Flow Charts:

Flow charts are perfect for depicting procedures. They utilise distinct symbols for each step or kind of action involved in the process. They aid in the documentation and comprehension process by enabling decisions, branches, loops, etc.

Testers commonly encounter flow charts in the test plan, test strategies, requirement artefacts (BRD, FRD, etc.), or other process documents.

The most commonly used symbols in a flow chart and their meaning are:

• Ovals- Various types of start and stop
• Rectangles- Processing or task representation
• Diamond- Denoting decisions

For a complete guide on flow chart symbols, visit Flowchart Symbols.

Flow charts simplify the understanding of a process or control flow. They aid in memorisation, comprehension, and quick reference.

See also => Writing Intricate Business Logic Test Scenarios Utilising Decision Table Technique

Here are two ways flow charts are utilised by testers:

a) Flow charts for control flow and statistical analysis:

Cyclomatic Complexity is a measurement that gauges a software program’s complexity. Having knowledge of the Cyclomatic Complexity aids in determining the extent of unit testing required for full coverage (refer to the links for additional information).

Flow charts are a preferred method for measuring Cyclomatic Complexity.

Let’s figure out how to calculate Cyclomatic Complexity for the following program with a control flow chart.

To measure Cyclomatic Complexity, create a control flow chart as demonstrated below and use this formula:

Cyclomatic Complexity: = Number of connections or Lines – Number of Nodes + 2

From the diagram, we have 7 nodes and 7 connections.

Hence, the Cyclomatic Complexity of that piece of code is 7-7+2 = 2.

For more information on how to utilise the control flow chart and Cyclomatic Complexity, refer to:

• The Connection Between Cyclomatic Complexity & Code Coverage While Undertaking White Box Testing
• McCabe’s Cyclomatic Complexity and Why Shouldn’t We Use It

b) Flow charts for illustrating the process:

Here is a flow chart representing a defect tracking process. It’s simple to understand and implement:

(Reminder: Click on the image for a bigger view)

Recommended Reading => How to Design a Flowchart in MS Word?

#2) State Transition Diagrams:

State transition diagrams are invaluable analysis tools when dealing with complex systems that go through numerous state changes.

For those unfamiliar with the concept of state transition, consider a light bulb controlled by a switch. The light bulb can be in the ON or OFF state, and the action of flipping the switch causes the transition from one state to another.

This can be graphically represented as follows:

Doesn’t sound complicated, right? Now let’s view a slightly more complex state transition diagram for a ticketing system, which is straightforward and simple to comprehend.

It’s noteworthy that state transition diagrams focus principally on the business entity and its transitions, not on visual page-by-page navigation.

Case Study: In our case, the core business entity is the ticket created via the application. While creating a ticket, you may progress through several pages:

• Page 1-> Select the number of passengers (adults, children, seniors).
• Page 2-> Select the ticket type (single day pass, weekly pass, monthly pass, etc.).
• Page 3-> Review and finalise details.
• Page 4-> Complete payment, etc.

So, there could be various visual page transitions, but the ticket is in the process of creation. Typically, we would not create a state transition diagram for visual transitions (although it’s possible if you wish), but rather for the state transitions of the core business entity.

Once the state transition diagram is created, it can be a useful tool for identifying end-to-end test scenarios and end-user transactions.

The three yellow lines signify three end-to-end cases that cover critical and frequently used sections of the application. This serves as a valuable tool for generating meaningful test cases and end-to-end acceptance tests.

For a complete explanation and real-world use of state transition diagrams, refer to: State Transition Testing Technique for Testing Intricate Applications

#3) Context Diagrams:

Seldom do software systems operate in isolation. Even though simple applications such as calculators and notepads may function independently, enterprise applications often interact with several other applications.

Case Study: A payroll system may interact with accounting software, systems tracking employee hours, and HR portals for employee information. Context diagrams are excellent at illustrating these relationships in an easily understandable manner.

The following is a context diagram for the payroll system mentioned earlier:

A context diagram provides a clear snapshot of a system’s interaction with other entities. Refer to this System Context Diagram for further explanation.

Context diagrams assist testers in understanding the system from a wider perspective and help draft test strategies that take into account the system’s inbound and outbound relationships with other entities. Even though creating context diagrams isn’t a typical part of the testing process, they greatly enhance understanding if available.

#4) Mind Maps:

Mind maps capture the incessant flow of thoughts as it explores various topics, with each thought leading to deeper and wider branches of ideas. They provide a diagrammatic representation of the primary idea and all its sub-thoughts.

Mind maps can be used for several purposes. While they may not be included in standard templates or