Agile Architecture Principle #4 – They build it, they test it

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.

One thought on “Agile Architecture Principle #4 – They build it, they test it

  1. I think the piece that is missing is that often, the team that builds the infrastructure only tests it in a manner they envision others to use it. Other teams also heavily test the system – not by functionality addressed but by functionality missed.

    The team must be prepared to react quickly because if they don’t the entire agile release train will grow weary and turn on the infrastructure team. This is further complicated by the comments I mentioned earlier under Principle #2

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s