Note: this is one in a series of posts under the category of “agile architecture”. In an earlier post, (Six Principles of Agile Architecture) we identified six principles that can help us reason about the challenge of architecting systems of scale in an agile enterprise.
Posts Principle #1 – The team that codes the system designs the system, Principle #2 – Build the simplest architecture that can possibly work and Principle #3 – When in doubt, code it out described the first three principles. In this post, we’ll discuss the Principle #4 ‒ They build it, they test it.
Agile is renowned for its emphasis on testing (“If testing is good, everybody will test all the time” – Kent Beck, 2000) and there can be no doubt that agile forces testing earlier into the lifecycle than any of our prior methods. This is a key benefit of agile in general and is one of the prime reasons why quality is materially higher in agile, and is accomplished without sacrificing overall developer productivity. Indeed, testing is so important in agile that I devoted an entire chapter to it in SSA, Chapter 12 —Concurrent Testing. “But this is a thread about agile enterprise architecture”, you might ask, “so why the lecture on testing”? Fair question.
My friend Philippe Kruchten once described architecture as ” take away everything in the system you don’t need to describe how it works, and what you have left is it’s architecture”. With this simple definition, testing architecture comes down to “testing how the system works without the details”, that means that testing architecture is testing the system’s ability to meet its functional (in the large scale), operational, performance and reliability requirements.
Clearly, this testing represents complexity at its greatest and who has the skills to test systems of the complexity that we are building today? Answer – the team that codes the system must determine how best to test the system. Moreover, with the enhanced power and complexity of today’s automation frameworks, the developers are likely to be directly involved in applying testing automation to their system. And when such automations isn’t available, it is necessary for the development teams themselves to develop, test and maintain the system tests and testing frameworks to test its ability to meet its architectural and functional requirements. Such a responsibility cannot be left to any other testing resources or outsourced functions or the team cannot then be held accountable for delivering a functional system within the iteration or release timebox.
So agile architecture Principle #4 is: They build it, they test it, because in agile, All Code is Tested Code.