Scaled Agile Framework - Automated Tests for Functional and Non-Functional Requirements

Agile approaches, and SAFe is no exception, emphasize the importance of constant feedback on whether the development efforts are "on track". Usually this means that the requirements are fulfilled in the right quality. And, obviously, this verification has to come cheaply and quickly. So we automate this using some kind of (unit) test framework.†

I don't want to talk about the real-life issues of actually doing this in large environments with lots of legacy code. I will safe that for later. Rather, what concerns me ist that the kind of tests we always talk about when "being agile" seem to be functional tests.†

One of the reasons I appreciate SAFe is that it recognizes the need for architectural work and incorporates it in Agile at Scale. SAFe calls this 'Architectural Runway', based on the fact that just enough architecture has to be there before the Agile Teams can work on the Features necessitating them.†

But how do we ensure that the architecture (conventions, patterns, laws, technologies) is being followed? I think, especially in Agile at Scale, there is a strong need for verifying the teams' work for adherence to architecture, just as there is for verifying the functional correctness of their work.†

This means that there has to be an efficient, i.e. cheap, quick, and repeatable way of doing this. I suppose that rules out having the architects review the code produced by the end of each iteration. The architects I know would applaud this notion.†

Thus, the solution here has to be automation as well. So, assuming that architecture, as defined above, can be articulated in a formalized way, we can use an†Architecture Verification Tool†which learns these conventions and checks the source code against them. Clearly, this will need to be exemplified (I've always wanted to use that word), and I will do this soon.†

But for the time being, just a rough example:†

Let's assume we want to create an App for iOS/Cocoa (admittedly a feat that has been accomplished a few times already). Let's further assume that our App is to be document based and that our architects have recognized this, as well as the fact that the good people from Apple already have a variant of the good old MVC pattern in place for this very situation. The only thing the architects need to do now is take this from the Apple site, like so...

Document architecture. In this architecture, a document-based application consists of a controller object for the entire application (NSDocumentController), a controller object for each document window (NSWindowController), and an object that combines controller and model roles for each document (NSDocument).

Source: apple developer site†

… and publish it as part of their Architecture Runway.†

Enter our Architecture Verification Tool. Now the tool knows, or rather, its master tells it, that for each view controller mentioned in the markup language of the storyboard, there needs to be a corresponding view controller which has to be an instance of NSWindowController. I know there is one assumption in here, but hey, what are iterations for?

Again: This example is very simplistic, but it shows how acceptance criteria can be inferred from software architecture rules and cast into, well, test statements. For instance, if we want to ensure that our aspiring programmers have not misused the AppDelegate and polluted it with persistence code, we tell them so and then have the tool check for strings like†NSPersistentStoreCoordinator in the AppDelegate class definition. I know that quite a few Apple examples actually put persistence code in there, but I'm not the only one who would beg to differ, at least in some cases. Let's say our architects agree with me.†

So, over time this tool, with the help of the architects, the tool expert and, very importantly, the development teams themselves will build up a set of rules against which the code base can be checked in a very time-efficient and inexpensive manner.†

I do think this is indispensable for Agile at Scale.†

© Markus Wagner 2016 ††