Enable Agile Testing through Continuous Integration

Continuous integration is one of the key processes that support an agile software development and testing environment. Sean Stolberg from Pacific Northwest National Laboratory wrote a great paper titled "Enable Agile Testing through Continuous Integration". In this paper he describes how a traditional software tester - transitioning to an agile development environment - put a continuous integration infrastructure in place. 

In doing so, he helped improve development practices and made possible his team’s transition to agile testing. Sean discusses his team’s initial motivations for adopting agile development practices and dives into the nuts-and-bolts implementation details. He shares their post-assessment of the implementation using Martin Fowler's “Practices of Continuous Integration” and concludes with a retrospective on implementing and promoting continuous integration within the context of agile testing. 

Find out how continuous integration can help improve your testing results and the quality of the software your team delivers. You can download the paper here from the Agile Alliance.

Related Posts:

• Continuous Integration with Hudson and .NET

Continuous Integration with Hudson and .NET

Continuous integration - the practice of frequently integrating one's new or changed code with the existing code repository - should occur frequently enough so that no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately. Normal practice is to trigger these builds by every commit to a repository, rather than a nightly (or weekly!) scheduled build. Automated tools such as CruiseControl or Hudson support this process.

We decided to use Hudson for one of our projects since we allready had a Hudson server up and running for Java projects. Hudson includes numerous plugins for a variety of source controls, build technologies, and notifications schemes including email and instant messaging. A web interface provides details of the current and previous builds. With help from Redsolo's Guide to building .NET projects using Hudson we got it up and running within a day.

Our setup is as following:

• Get the source code from our Subversion repository.
• Link change logs to the repository browser using ViewVC.
• Build the project using MBuild.
• Run the tests using NUnit and display the results together with a trend graph.
• Publish artifacts from the build (triggered builds).
• Run FxCop on the created assemblies and display warnings (linked with source code) and a trend graph.
• Search the source code for TODO comments and display the open tasks with links to the source code.
• Create documentation using Doxygen.
• Deploy the whole build on a dedicated test server.
• Notify project members about the build result by email.

So far we are really impressed by Hudson, but I will tell you more about our experiences when we have used it for a little longer.