“Architecture is a cornerstone of good testability!”
(Richard Seidl)
Let me say this up front: I’m not a software architecture expert. Other people are. I’m more of an architecture admirer, always happy to see new patterns, frameworks and strategies that move us forward. For me, architecture is also a cornerstone of good software quality. It doesn’t just help developers write clean software. It also helps us testers and quality folks with one really, really important thing: testability.
Warning Signs: When Architecture Blocks Testability
I’ve heard statements like these on projects more times than I can count:
- “No, we can’t write unit tests, the architecture won’t let us.”
- “Uh… performance problems. Yeah, we know, but changing the architecture… you know, it just grew that way over the years.”
- “Well, you can’t get at the interfaces that easily. And they’re not really official anyway.”
And on it goes. All signs that nobody takes care of a sensible software architecture, or that people simply started coding away. That’s fine at the very beginning of a piece of software, but fairly soon it has to be clear which structures, interfaces and patterns you use. And a view of the architecture has to emerge.
It never stops amazing me how teams of 10, 20, 30 developers and testers tinker away at software while constantly wrestling with this technical debt. Although, strictly speaking, it isn’t technical debt at all, it’s organizational debt. But let’s leave that for another day. An unbelievable amount of money goes up in smoke coping with these shortcomings instead of starting to fix them.
Why Software Architecture Has to Keep Evolving
Besides the projects that work with no thought-out architecture at all, there are others that, I believe, fall for a basic misunderstanding: that a software architecture gets defined once at the start and then holds forever.
That doesn’t fit my world at all. An architecture certainly isn’t something I tear down and rebuild every few days. But I do want to see it evolve and stay flexible. And I don’t just mean upgrading to the latest version of the framework. I mean looking at the architecture with questions like these. What does our software architecture need to look like
- so that today’s and tomorrow’s requirements are easy to implement?
- so that it supports the development process?
- so that it fits topics that are just emerging?
I find that last point especially exciting. New innovations, such as MCP servers in AI right now, come out of projects and teams that run current architectures. If you use equally current architecture paradigms, implementing these features is much easier than if your own implementation reflects the state of the art from 10 years ago.
Testers and Architects at One Table
In my opinion, software architecture is massively underrated. A real shame, given how much it matters.
So: go find the architect on your team and grab a coffee together 🙂
