Software architecture overviews and me have a history. To start with, I’ve seen a few and most of them looked different to each other, by type. So I was often slightly confused about what all would fit that label and what would rather be a communication overview, a software design sketch, or just a happily colourful image of a few shapes, with some of them connected, somehow. And than there were the projects where I’ve not had an architecture overview available at all – even though annoyingly asking for it every other week.
But why even ask for it, why care?
I find software architecture overviews – in whichever shape they come – help understanding the big picture. And that I find immensely helpful when testing, as it helps me to …
Make sure I test the right thing.
Are the parts affected even executed when I step through the software? Am I really testing the component that changed, that I want to test? Am I aware of all possible entry scenarios? Exit scenarios? Ripple effects?
Plan my testing scope more efficiently.
What components are affected by the change that I’m testing? Can I sidestep, are there scenarios that do not touch my area at all? Can I safely skip test scenarios?
Be aware of risk and impact, and prioritize accordingly.
Are the changes in a critical area, in a component that is often, always, in crucial cases executed? Or is this a rarely used path through the software? If this part would be flaky, how badly would that impact the most common use cases and our customers?
Get inspiration and test ideas.
Changing perspective can generate a lot of valuable test ideas. Looking at an architecture overview can help trigger new ideas and questions. Try to think from the software’s perspective – how is it affected by the change? What could make it horribly uncomfortable? Are there any neighbouring functions, features, components that I overlooked in my test planning and really need to consider?
Communicate more efficiently with developers.
Not only more efficiently, also way more pleasantly – from my experience, developers who care will be happy to see that you also care, and will be happy to fill in any knowledge gaps you have. I’ve only seen respect grow when getting deeper involved and asking questions about the inner workings of the software. Collaboration is just a brilliant experience.
Visualize how data travels around.
And if the change I’m testing introduces any differences there. To be aware of your (test) data is important, as bad data can crash systems – and that might be encodings, length, mass, values. To know what needs to be considered as input values and what the system is able to process helps to test more efficiently.
Getting towards a more independent and efficient test setup.
Components are generally linked together in certain ways and can be developed independent of each other. When I’m aware of the interfaces, of input and output values, I can look into replacing some components by mocking or direct interaction. And that enables me to develop a more independent test setup where I can already test changes from one component, without being blocked by unfinished development in other components, unnecessary dependencies or unwieldy ways throught the system.
Have fun, unabridged.
Not kidding. I’m a big fan of understanding things. I don’t want to die stupid, I find it oh so motivating to understand how something works. And I’ve got a feeling that’s a human universal – why not share it?
This is only an unordered list of some benefits you can take out of being aware of your products software architecture. There are others – detecting boundaries, getting to know context, finding out what part touches which, planning automation and so forth. And if that’s not convincing enough – I’ve actually been asked in an interview to do exactly that, to draw an software architecture overview of my actual project – so it must be relevant, right?