Rigour with development process

The agile team has a rigorous testing process with different types of automated tests to ensure high quality products. This is achieved through adapting to use a test driven development (TDD) approach with an automated testing environment. Prior to agile adoption, Akldevelopment had no automated testing environment.

Figure 22 Rigor with development in relation to productivity-rigor trade-off - Akldevelopment

4.3.6.2.1 Unit tests

The agile development engineers are required to write unit tests for stories that they implement. All their code is driven by unit tests where the engineers write unit tests to validate individual functions. Here, they write a unit test before writing any code for a function related to a story a pair is implementing. This practice ensures that their quality standards are being met and to identify and eliminate defects early in their development process. This practice also provides them with the benefit of refactoring (making the code as efficient as possible) as a story is implemented.

Always write unit tests before code … it is not like we spend 3 hours writing unit tests and then 5 hours coding … spent 30 seconds writing a unit test, one line of code … refactor it … it happens every minute. (Principal engineer)

Akldevelopment’s agile test driven development has an automated and continuous integration system which helps to detect integration problems, gives an early warning of

Profile of development environment

In-house development Size of IS department Project duration

Legacy systems development Responsible autonomy

Productivity-rigor trade-off

1. Productivity

broken code, instantly evaluates unit test changes, and facilitates the availability of builds for systems testing, product releases and marketing.

Our software sells for multi million dollars … is huge, can’t run all the tests every single time you change a line of code … need to use integration system to make sure that when I commit some code, don’t break [other] modules. (Principal Engineer)

4.3.6.2.2 Adapting unit tests with mutation tests

This agile team has adapted to using the JUnit testing framework for writing unit tests. In November 2006, based on a suggestion by the engineering manager, the team adapted to enhance their TDD practice by including mutation testing to help determine the effectiveness of their unit tests. Using mutation test, the engineers are now able to determine the quality of their unit tests during implementation and can improve them to enhance the overall quality of the new features.

Mutation testing … mutate the code and run all the unit tests again, if they still pass then something is wrong … definitely have a defect … is basically about assessing the quality of the unit tests. (Engineering Manager)

4.3.6.2.3 Systems testing

Before a major release, Akldevelopment has a four week systems testing phase for their product. With this agile team, they have adapted to use an automated acceptance testing environment for their internal releases. They have adapted to use a complete automated acceptance testing environment for their end-to-end functional tests replacing manual systems testing. The acceptance tests run constantly with their continuous integration systems to make sure that their code achieves quality gains.

Don’t do system testing whatsoever … have automated acceptance testing … alternatively run manually, not the best approach towards improving productivity … in that sense we have

adapted, built in the acceptance tests from day one.(Engineering Manager)

But they [on-site customer] would go at their own time and just look at the screens and make sure things look fine. And then try a few of the functions on the screens and then they leave. (Principal Engineer)

The team adapted to use the Fitnesse testing tool to automate story tests, enabling them to test business logic. This tool allows their product analysts to explain a story using a tabular set of data. The engineers implement the code behind the test and the product analysts will test to see if that code is working.

Fitnesse test … we use a tabular set of data inside a Wiki that lets the customer express concepts

through tables of data … tests become part of the normal continuous integration and build

system. (Principal Engineer)

4.3.6.2.4 Adapting acceptance tests

The agile team adapted to use Selenium as a test tool for testing the user interface by running it directly in a real browser such as Firefox or Internet Explorer. Selenium involves writing HTML pages that contain Selenium tables. Selenium is preferred to other testing tools that simulate a browser. However, some engineers found

implementing the Selenium test challenging.

It is important that we write functional tests in the browser that tests the stuff that we can’t test in Java …tried Selenium, a much better way of testing the UI … strong and powerful. (Engineering Manager)

For me to write a Selenium test straight off and start coding the web page is very difficult because I don’t know what the IDs will be and some of the web page stuff is automatically generated. (Principal Engineer)

In July, 2005 the agile team agreed to adapt their Selenium tests by writing Java code that got executed during the build process to produce HTML code. This adaptation was proposed by engineers since they could not refactor HTML code. The agile team accepted this adaptation as necessary for them to be able to refactor all their

implementation to make their code more effective, as there is no refactoring tool for HTML code.

It is easier for us to refactor that code, write that code in Java. (Engineering Manager)

Writing J unit tests and then writing Java code … is fine for me because I understand Java. So writing a J unit tests for me isn’t really that difficult. (Principal Engineer)

4.3.6.2.5 Adapting build system

With this agile team, the committed code was put into a single instance of CruiseControl, a Java-based framework for a continuous build process with their version control system. Overtime the code base grew so that it was no longer efficient. In August, 2005 their build system was adapted into smaller CruiseControl groups where major components have their own CruiseControl. The agile team adapted their build system to make it more efficient. Initially, their build process would take up to four and half hours to build once code was committed. This duration for build process was quickly recognised by the engineers as inefficient because they had to wait for long

periods of time to know about the broken builds. This resulted in engineers not able to deliver their sprint commitments on time, fixing the build from the previous sprint during the next sprint cycle.

When we started, the build would take up to 4 ½ hours … have adapted in such a way that we can split it up … [for] major components one cruise loop each … have about between 13 and 15 cruise loops. (Engineering Manager)

Running the build, we need more hardware … takes too long to run the build … so that individually we could run our builds over many machines and it would be much quicker. (Engineer)

This adaptation allows more frequent builds where they are able to run ten to fifteen builds per day from two or three builds per day in the beginning. The engineers get feedback on the broken builds more quickly helping to increase the team’s productivity in meeting their sprint commitments. In the beginning, the agile team experienced a lot of broken builds, which now has improved considerably.

We could have built the entire system in a single cruise group, within 10 minutes … but we would not build more often … slow down teams. (Engineering Manager)

4.4. Overt factors

This section provides detailed information on Akldevelopment’s agile approach adaptation driven by the overt factors or intellectual roles of software development methods. Figure 23 shows these overt factors as identified in Fitzgerald’s adaptation framework. First, information on project management adaptation at Akldevelopment is provided