Yesterday, I talked about architecture and design, and their importance. There is a whole lot of resources on the Internet to learn about the various architecture models, and I would encourage you to go through them. In today’s blog, let’s look at an example of how to convert business requirements to architecture, and how to test it.
Business requirements typically appear relatively simple to start with, but when they are elicitation is done on those and clarifications sought, more and more details come into picture, and this has been fabulously captured in this example. It is interesting to note the way the requirements initially expand to a conceptual architecture, and eventually to a detailed architecture. This is why, business analysis tasks should not be under-estimated. They should be given priority.
As that article states, it is the user stories (or the equivalents) that map to the requirements, not the architecture. User stories should also align with the architecture. At the same time, from a Software Testing perspective, would it be correct to just ‘test’ the user stories and be satisfied that the system is working fine? No. The tester’s job starts not with analyzing with the user stories, but when requirements are captured and analyzed, and an architecture is built.
There are several things that need to be validated and verified apart from testing user stories:
1. Sufficient care is put into designing the architecture, but it needs to be validated and verified if it satisfies the systems blueprint for fulfilling the business requirements.
2. Whether the architecture takes care of all the design considerations
3. Traceability from User Stories (or their equivalents) to Architecture
4. Traceability from User Stories (or their equivalents) to Business Requirements
The testing strategy for a system is not the testing pyramid that’s being circulated widely (may be it is the developers’ view of how they would test), but it is about paying attention to each and every detail of business requirements, solution architecture, design, user stories (or their equivalents), and their interconnections and traceability.
For detailed Software Testing strategy for your product, feel free to reach out to me.