Uncover the Complexity of Simple Looking Things to Test Better
How to gain technical insights of the system under test to uncover hidden complexity and risks.
The graphical user interface is one part of the software. A part that acts as a beautiful curtain in front of complex things. This curtain is important, because this is how users experience most products and services. Therefore, this is the layer on which the most testing often happens.
Nevertheless, it is also important to pull this curtain aside or even to the ground.
In this post, I will show approaches to help you explore and understand the technical aspects that lie beyond the graphical user interface.
Hidden Complexities
A complex state machine may lie behind a series of web pages filled with forms and validations. A single click of a button can trigger a series of events, some of which may occur asynchronously. The information displayed on a mobile app may be provided by a backend for frontend1 that retrieves and processes data from many different systems.
Looking at the graphical user interface alone is insufficient for understanding the software's inner workings. Without this knowledge, it is difficult to assess risks, conduct proper testing and identify problems that matter.
Let’s change that.
3 Ways to Gain Insights
Here are three ways to gain insights on the inner workings of software systems.
Observe the System
While you explore and experiment with the system trough its graphical user interface, you can use tools to observe the hidden behaviour. Taking a look at this can help you to learn more about it. Based on your observations you can ask questions and use the gained knowledge to identify risks and to generate new test ideas.
Here are some ways to gain insight by observing the system on a more technical level:
When you test a web app, you can open the browser’s developer tools to see the network traffic. There you can see what the app sends to the backend (request) and what the backend returns to the web app (response). Take a look at the data being communicated and how it is structured.
The same can be achieved with other apps that act as a frontend and have a backend, such as mobile apps. You can put a proxy between the frontend and backend to monitor their communication.
Next, you can take a look at the backend logs produced by a specific request. Depending on how extensive the logging strategy is, you can observe the flow of data, the components involved, and the decisions made.
If you have a database, you can see how a specific request alters the data within it. You can also see how the data is structured and which dependencies exist between certain pieces of data.
This way you dive top-down into the system under test.
The Developer Interview
Developers usually have the most knowledge about the technical details. So, it makes sense to have a conversation with them to benefit from their knowledge.
One way to approach this is to ask them to explain the feature top-down. When a user visits a web page or clicks a button, what exactly happens? From the web page that is our beautiful curtain, over the web server that does the processing, to the database that stores data.
This gives you a better understanding of how the technical process looks like and what components are involved.
You can also ask questions to identify risks:
What challenges did you face?
What surprised you?
What was the most complex or most difficult part to implement?
Did you face any parts prone to errors?
Was the logic from other parts reused?
Based on your new gained knowledge about the software and the possible risks, you can generate new test ideas and address risks by targeted testing.
Make a Visualisation
I find visualisations incredibly helpful. They help me to reach a common understanding with my colleagues and to model systems as I understand them.
You can visualise an overview of the systems and components involved in a specific feature or service. You can also picture how data flows trough the system under test.
This helps you to to understand responsibilities, who certain business logic is, as well as the impact the changes can have on other parts of the software and its dependencies. You may also identify unknowns, such as not knowing what a particular part is responsible for or why it is needed.
Visualise it and discuss your visualisation with someone else to see what you got right, what is missing and what you got wrong. Then use this knowledge and improved understanding in your testing.
Stay Critical
No matter what you learn or think you know during this process, stay critical. Ensure you build your test strategy based on proven facts, not assumptions and false information. If you are unsure, run experiments to confirm your understanding of the system.
I hope these approaches help you to make the most of your given time to test.
Kind regards,
Florian
Backend for Frontends Pattern, Microsoft