How diagrams could help you with your Test Strategy
Introduction
I’m pursuing a Software Architecture MBA, and in these six months, I’ve learned a lot about the different ways we can represent our software on different levels. We can use diagrams to describe business requirements, application design, database, infrastructure, and internal operation. I was thinking a lot about how I can use this knowledge to create better Test Strategies, and I’ll share it with you in this post.
What software architecture means
You can find this standard definition at Wikipedia:
Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. — Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley.
I want to call your attention in this part: Each structure comprises software elements, relations among them, and properties of both elements and relations.
This definition was talking about software elements, relations, and properties, and it is all that we test in software. So, use this kind of information will help us a lot to test the right thing in the right way.
I like another definition which you can find in the Martin Fowler site.
“Architecture is about the important stuff. Whatever that is”
As important stuff, we can consider which characteristics are essential to your product, like performance, flexibility, scalability, feasibility, reusability, fault-tolerant, and security, for example.
And again, if we are talking about the important stuff, we need to test this to ensure everything is operating as expected. All these architecture decisions will impact on what we’ll decide as your Test Strategy.
Diagrams and Test Strategy
My objective in this text does not go deep in the characteristics and how to achieve then, but give you some tips about how you can use the architecture inputs to plan your Test Strategy.
Instead of just automated coding tests, you need to design your tests first. Depending on your architecture pattern (Serverless, Microservices, Event-Driven, Monolithic), you’ll have different options to define the better Test Strategy. If you are working in a Microservices world, you will have a lot to cover in the integration layer. If you have legacy code in a monolithic, you will invest in the high levels of the pyramid because it would be hard to test the components.
Before you start coding different types of tests, it’s essential to know what you will test and the priority parts of your product. Because this is important to have a clear vision about the big picture and integrations so you can make better decisions, I’ll give some examples of how diagrams can help you to think about what you’ll test.
Business Process Model and Notation
The BPMN will help you to understand the actors involved in the process, and then you can find your positive and negative test cases. With this diagram, you’ll have an excellent flow view of each method.
Context Diagrams
The context diagram will show you the boundaries in your system. Look the following example:
In the diagram above, you can see what the boundaries were; you have integrations with internal systems and external services. If we are talking about different APIs, you can create contract tests to ensure the pact between these boundaries. If you have contract tests, you are safe to develop Test Doubles to use in your regular tests to avoid problems like slowness and unreliability. Sometimes you have rate-limits to access these external sources, and then you are not able to perform regression tests for each code change. The mix of contract tests and test doubles can help you in this situation. Maybe you’ll not be able to perform any automated test in one or more boundaries, but with this vision, you can communicate how far is your coverage and assume the risks not to test some components.
Sequence Diagrams
The Sequence Diagram will help you to understand the object interactions in a time sequence. It’ll help you a lot to design your test cases and define what asserts you need to do. Sometimes you are testing a flow which impacts different process, and you need to guarantee all operation are performed in the right way. For example, when you buy a product, the quantity needs to be updated in the stock, or when you withdraw money from your bank account, the system needs to give you the money and decrease the same amount in your account.
General Architecture Vision
And the general architecture vision will help you to define some non-functional tests like performance and security.
Conclusion
Architecture diagrams and documents can help us a lot to understand better what is essential for our product, what are the critical parts, how we can guarantee the boundaries, and all this information is useful as an input to create a Test Strategy and define what you’ll test.
