5 Important Diagrams That Testers Need to Learn How to Use

If not for pictures there were be no recordings of early history, passable knowledge, and evolution of language.

Not to overly dramatize, but diagrams have their own special place even in a world with highly evolved and sophisticated forms of writing and expression.

In the technology industry, our diagrams are dear to us.

Here are some of the prominent ones that we testers come in close contact with often and how we use them.

 5 Diagrams That Testers Need to Learn How to Use

 

Here we go.

#1) Flow Charts:

Flow charts are best for process illustrations. They use specific symbols for each task/type of action that is carried out within the process. It allows for decisions, branches, loops etc., making it a perfect tool for documentation and understanding.

The testers will usually find the flow charts in the test plan, test strategy, requirements artifacts (BRD, FRD, etc.) or other process documents.

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

• Ovals- For start and stop
• Rectangles- For processing/or a task
• Diamond- For decisions

For complete information on flow chart shapes, check out Flowchart Symbols.

To understand a process or flow of control through a flow chart is super simple. It helps with remembering, understanding and serves as a quick reference.

Also read => How to Write Complex Business Logic Test Scenarios Using Decision Table Technique

 Here are two ways we testers use flow charts:

a) Flow charts for control flow and statistical analysis:

Cyclomatic Complexity is a metric that helps us measure how complex a particular software program is. One of the uses of knowing the Cyclomatic Complexity is that it helps us understand the extent of unit testing to be done in order to achieve complete coverage (more information and links below).

Flow chart is a go-to method to arrive at this measure.

Let’s learn how to calculate Cyclomatic Complexity it for the following program through a control flow chart.

Simply create a control flow chart as shown below and use this formula:

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

From the diagram, the number of nodes are 7 and connections are 7.

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

Need more information on how to use the control flow chart and Cyclomatic Complexity?

Check this out:

• Correlation between Cyclometric Complexity & Code Coverage while doing White box testing
• McCabe’s Cyclomatic Complexity and Why We Don’t Use It

b) Flow charts for process illustration:

The following is a defect tracking process represented in a flow chart format. As you can see, it is super easy to absorb and implement:

(Note: Click on image for the enlarged view)

Suggested Read => How To Make A Flowchart In MS Word

#2) State transition diagrams:

State transition tables or diagrams are great analysis tools when you are looking at complex systems that undergo a lot of changes from one state to another.

For those beginners out there who are thinking, ‘what is state transition?’- Think of a light bulb that is controlled by a switch. A switch can be flipped ON/OFF. So, the state that a light bulb can be at a given point of time is ON or OFF and the event/action causing it to transition from one state to another is the flipping of the switch.

This can be shown in the form of a diagram or a table. Like below:

Simple, isn’t it? Let’s take on something a little more complex. Look at a state transition diagram for a ticketing system. It is pretty sstraightforward and easy to comprehend.

Please note that state transition diagrams are usually business entity-centric and not visual page by page navigation-centric.

For example: The core business entity in our case is the ticket itself that is created through the application. The first part, making the ticket, could involve navigating the system through a few pages:

• Page 1-> Select no. of travelers- adults, children, and seniors.
• Page 2-> Choose the type of the ticket- a day pass, a weekly pass, a monthly pass, etc.
• Page 3->Review details and finalize.
• Page4-> Make payment, etc.

So, there might be many different visual page by page transitions but the ticket itself is in the state of being made. So we normally don’t create an ST diagram for visual transitions (you can if you want to, but it is not as often used), we do it for state transitions of the core business entity.

Once, the ST diagram is created, you can use it to easily identify the end to end test scenarios and end-user transactions, as follows:

The three yellow lines are 3 end-to-end cases which when tested, will cover the most critical and most used areas of the application. This is such a beneficial tool to create meaningful test cases and end to end acceptance tests.

For a much more comprehensive explanation and real-world usage, check out => State Transition Testing Technique for Testing Complex Applications

#3) Context diagrams:

Software systems rarely function as independent units. Simple Applications such a calculator, notepad, etc. might work on their own, but enterprise application often interfaces with many other applications.

For example: A payroll system might interact with accounting application, time-sheets system for employee hours and the HR portal for employee details. Context diagrams are excellent diagrams that showcase all of these relationships in an easy to understand way.

The following is a context diagram for the payroll system just described:

A context diagram very clearly shows the context of a certain system with all the other entities that relate to it. For a simple explanation, check here =>

For a simple explanation, check here => System context diagram

Context Diagrams help testers understand the system in a broader sense and aid in creating test strategies that include these inbound and outbound relationships that the system has with the other entities.  We might not create a context diagram as part of our testing process, but if available, it aids great comprehension.

#4) Mindmaps:

A mind map tracks a busy mind that hops from topic to topic; every thought getting deeper and branching out wider with each idea.  It is a diagram form of just starting with your main idea and documenting every single sub-thought that originates from it.

Mind maps can be used for anything and everything. Although, they are yet to make an appearance in the IEEE, CMMI or other standard templates or process documents, they are still a very popular part of the software industry culture.

One very popular use of mind maps is to track exploratory testing. (I know, I know, you are thinking, why does exploratory testing need to be tracked at all? It is because, with rapid development cycles, agile and other faster methods of software development, it is becoming less likely for testers to find the time and scope for complete documentation. This means, the extent of exploration is growing and it needs to be fortified. Mind maps can do just that for you.)

For example: The following is a diagram for an e-commerce application where you are simply tracking your testing with a mind map as follows:

Testers might not get the mind maps as inputs. But we might see situations when we have to create them. To do so is very easy. Start with your central idea or starting point and follow where your thoughts take you.  There are many simple and easy free online tools that you can use for mind mapping. This is the one I used to draw the above map here.

For more information and tools, check out => Mind Mapping in Software Testing – Ways to Make Testing More Fun!

#5) ER diagrams:

Entity-Relationship (ER) diagrams are used for Database modeling. They help us understand the tables, their fields and how fields in one table relate to fields in other tables in the DB system. It shows the components of your DB system and the relationships between them in a visual way.

ER diagrams also act as an initial trial run of the DB model and visualization before DB systems are designed and built.

ER diagrams have entities (the instances of DB tables) and their relationships (one to one, one to many, one to mandatory, etc.) represented using boxes and crow’s feet connectors. ]

There are many variations to the ER diagrams, but the simplest version can look as below:

Image Source

For a quick introduction and explanation, check:

• Entity Relationship Diagram (ERD) Training Video
• Entity Relationship Diagram (ERD) Tutorial

#6) Bonus: Mock up screens/Wireframes:

Wireframes are either HTML or simple images (screenshots) that show us the future UI page/component diagrammatically.

Wireframes are a blessing for testers as they make it super easy for us to visualize the final product and be able to better their test design analysis process. This means better test scenarios, better test cases and in turn, higher test effectiveness.

Wireframes can be simple hand-drawn images, or interactively created web page structures or any other diagrams that are representative of the final system.

A simple wireframe for the login screen can be as below:

Here is a quick link to understand the way QA teams use wireframes for early testing and some tools to create them => Wireframes – Should They Really Be Tested? And If So, How?

To wrap up- How can you create these diagrams if you need to?

Mostly, testers interpret most of the above mentioned diagrams. But rarely, we might have to create them. MS Visio and SmartDraw are great tools to use. However, if you are looking for something free and light (no installation and setup), check out here.

When you do not have access to the internet and all you have is your word or paint you can use the shapes available to create these diagrams (well, at least most of them). This is my least favorite method because it is time-consuming and not as user-friendly, but it will do.

About the author: This article is written by our team member Swati.

So, what diagrams do you use and which are your favorites?