Improving your test strategy analyzing the application architecture risks

Different factors are important when defining the test strategy for a software application. The business needs, your team member’s skills, the application architecture, and its risks are some examples of factors. I recommend reading this article with more details: Bad Test Strategies and How You Can Avoid Them.

The application architecture factor is usually complex and can change considerably depending on the components involved in this architecture. Each of those components and their integrations can present different challenges and risks for the application, and you will need to consider all those when creating the test strategy. It will help you mitigate them, which I want to explore in this article. For example, I wrote another article about asynchronous applications: Creating a test strategy for asynchronous microservices applications.

Many software applications share some common patterns and technologies, following trends, which can help reuse pieces of other test strategies. For example, an event-driven architecture will follow similar principles, and in the same way, similar risks. But most architectures will differ at least a little bit, considering the integration of some components or technologies applied in the solution. For example, that same event-driven architecture mentioned above can use different message queue technologies or even be deployed in a specific way (on-premises and Cloud), making a difference in those components integration (also includes more risks).

As you will see below, this concept is applicable in different kinds of architecture pieces, including back-end, front-end, mobile, etc.

Let’s exemplify more cases of specific components that could be part of your solution and its risks that would affect your test strategy:

• The architecture includes a BPMN process, where the goal is to give more flexibility for the business to define part of the application logic to solve multiple needs. Camunda is an example of a BPMN solution. Once part of your application logic is dynamic, the strategy to validate the correct behavior will be different from another common back-end service. The integration with other services can be an inherent risk too. In the image below, there is an example of architecture using Camunda.

Camunda architecture example. Reference

• If you need to integrate with some legacy services/applications, those services' performance and resiliency are some examples of concerns. As a solution, you could have a third-party full life cycle API management component, for example, Apigee or Mulesoft, that will need a specific approach to validate the integration with your different clients and the legacy services.

Apigee simple architecture example. Reference

• Here is an example related to the front-end: let’s say that your application uses some CMS (for example, WordPress) to make it easier for the business area to change the website content. In some way, you have more risks with layout and resolutions due to its incorporated flexibility. So, the test strategy will need to be different from the one that validates static content.
• An example for mobile applications: If you use a server-driven UI framework to generate the user interface of your application, the strategy will be different from a typical native Android app, as the context of your app will be more focused on the back-end. A simple API change could bring a serious crash in the user interface.

Server Driven UI in action. Back-end code will be used to define different UI elements. Reference

Once you have mapped the different risks involved in your architecture, you’ll create a test strategy that will be more efficient, where you’d evaluate what kinds of tests you will need to perform that will mitigate the risk that they will need to cover.

I admit that in certain cases, it is not an easy task to try to identify all those risks and gaps for all those different possibilities of architecture. You and your team need to be aware of what is the meaning of each component of your application solution to identify all those details. I like to say that you need to deeply understand how your application works, to identify how it could not work.

When we analyze the infrastructure that will support this application, we need to pay attention to even more potential risks and challenges. For example, if we are in a cloud environment, there are many services and different configurations that can be applied. How can we guarantee that we integrated those services correctly and applied the proper configuration? Maybe you could consider that there are just some minor breakpoints here, but a simple incorrect VPC or security group configuration could be a problem for your application. So, many potential failures can also happen at this level. Since it is a broad topic with many things to discuss… maybe in another article we can talk more about those infrastructure risks. 😃

In conclusion, we saw how all those application architecture risks could be useful for defining and optimizing your test strategy. It can be a complex process in some cases, but it is important to mention that you don’t need to do all this process alone. So, don’t worry if you don’t know some of the technologies mentioned in this article. You can receive a lot of useful information and inputs from the other team members, collaborating in creating an efficient test strategy. Understanding deeper some new concepts, it’s a constant process of evolution!!

Thanks to Samanta Cicilia and Leonardo Galani for reviewing it!!

Here is a few other suggested reading:

How diagrams could help you with your Test Strategy

Is High Quality Software Worth the Cost?