Creating a successful product relies on two things: excellent quality and fast delivery.
To achieve both of those things you’re going to need to do a lot of testing. Now, it would be pretty difficult to ensure that you are delivering a high-quality product on a tight time scale if testing can only be performed manually. Simply put, it would just take too much time.
That is why writing end-to-end (E2E) tests has become an integral part of the QA team’s daily routine.
End-to-end testing refers to a software testing method that involves testing an application’s workflow from beginning to end. This method basically aims to replicate real user scenarios so that the system can be validated for integration and data integrity.
Still, when it comes to automation, it is not always obvious to understand which of the user flows should be covered by automated tests. You might ask: “can we cover everything?”. Sure, that would be the ideal scenario, however, in real life, we need to define the scope of our tests based on risks and time commitments.
To do this effectively, we need to measure the size of the system and mark out all the possible user paths in it. Naturally, we need to find the right “instrument” for defining the flows, which for instance, could be a test case management tool.
Still, if you are more like me, you probably want to use a method that provides the ability to document and visualize the flows at the same time while also helping to calculate the numeric values of the test’s coverage.
For me, that means one thing: mind maps to the rescue.
How do we use mind maps?
Mind maps are tools used to represent ideas in a graphical way. We employ mind maps to structure information during brainstorming sessions.
Mind maps always include:
- Center node: this is the main topic or subject.
- Child nodes: these are the ideas generated from the center node.
Every other node is added afterwards following the tree structure. Additionally, colors, icons, links and comments can be used to represent other aspects of the user flow.
But how does this help us when we are tracking the coverage of E2E tests?
Well, instead of adding new ideas, we can simply add a user’s actions in the form of a new node.
User flows
As mentioned above, we use mind maps to mark a user’s actions and combine them into flows. Our current approach looks like this:
- Assign a generic center node which we can name “user flows”.
- Label the child nodes with user types such as “guest user”, “logged-in user”, “suspended user”.
- Create all other nodes with specific exact user actions such as buttons, links, or forms names.
- Check to see if certain functionalities are reachable from different parts of the system. If this is the case, there is no need to duplicate them – we can simply use links to these specific nodes.
In the example below, we can see that the guest user has two possible flows to follow: “sign in” or “sign up”.
When the user selects “sign in”, they should either enter the credentials and proceed to the user type “logged in user” or they can move to “sign up”.
Notice how instead of duplicating the “sign up” action, we can simply use a link to the existing node which is represented by the arrow icon.
What are the benefits of using a mind map to visualize user flows?
- You can see all possible user flows (or at least most of them) from different parts of the system.
- It is easy to insert a new node or move a group to another place.
- You can avoid duplication. For example, if there is a new functionality in the “sign in” page, you can simply add a node there without breaking or changing anything else.
Test coverage
We already know that mind maps can help us to structure system features into user flows by using nodes and links but this is not the only possibility this tool provides.
You can also use mind maps for tracking the coverage of E2E tests. For instance, you can use different types of nodes such as colors, forms, and buttons and make calculations based on these variables.
Generally, we follow this structure to track E2E tests:
- Mark the user’s possible actions for E2E testing with one type of icon (e.g. a black circle) and mark the actions which are already covered by automated tests with something else (e.g. a green checkmark icon).
- Count the number of covered and not yet covered actions.
- Calculate the final result based on a simple formula: covered actions/possible actions.
In this example, we can see that the “sign in” and “enter credentials” steps are covered by E2E tests, while “forgot password” is not.
The coverage ratio is represented here as:
4 (green check marks) / 5 (black circle icons) x 100% = 80%
Every mind map creation tool can have a different set of available functionalities. We chose Mindmeister as it makes it easiest to count the number of nodes – all it takes is the click of a button and you just need to mark the nodes with different icons (as in the provided example).
For better visualization, we also colored the nodes: green – for a user’s action that is covered by an automated test; red – for an action that is not yet covered; and grey – for an action that is not within the scope of the test.
Not all flows can be (or need to be) covered by tests. A QA engineer’s goal is to write tests for the main flows of the system and keep the test suite manageable (the more tests you have, the more time they require to update).
If you are running a lot of tests, you will find that some cases cannot be implemented due to technical limitations. In this example, the “FAQ” action is marked in grey – this indicates that this flow exists but a test for it will not be written.
The benefits of tracking coverage of E2E tests with a mind map
- It provides the initial view of which part of the system is already automated.
- It helps us to calculate the numeric value of actual coverage.
Why do we use mind maps?
- The maintenance is easy. There is no need to go through a bunch of various test cases when updates are needed.
- It can be used for different purposes. From exploratory testing sessions, to onboarding new people to the project. Mind maps even show us the numeric value of automated tests coverage.
This is not a silver bullet but it can really help on a day-to-day basis. If you do decide to try this approach, please do not hesitate to share your experience with us.
Zyro – the easiest way to build a website
Join the conversation
Your email address will not be published. All fields are required.