Testing is Essential to Agile SCM

where people do not have traditional roles and everyone has a broad skill set, it is likely that many organizations have some sense of boundaries.

  • The Software Developer
      • is responsible for writing unit tests for any code she touches and for running any tests available so as to verify the stability of the codeline. 
      • might also work with the QA Engineer to write functional tests.
      • might help maintain build scripts for modules they understand architecturally
  • The QA Engineer
      • can help with defining functional and integration testing
      • can look at incorporating test coverage reporting into the automated suite - to ensure that code is appropriately exercised by those tests, and to maintain the desired levels of test coverage for new functionality
  • The Release Engineer
      • can enable the development team to do local builds
      • help define criteria for acceptance at various levels

Process and Workflow Testing
Many companies use workflow and tools to help automate their process, e.g. having defects being reported and going through a certain lifecycle with different sign-off points and different levels of authority. Agile teams tend to keep these processes as simple as possible - allowing people to make decisions flexibly based on their own judgement. But what happens if you are in a situation where this is not deemed sufficient? Don't forget that changing a process requires testing to ensure that the process now does something slightly different. It is very common to find organisations making process changes on the "live" system in a rather uncontrolled manner.

So, treat your workflow process as something that needs:

    • change control and configuration management - can you reliably report on what was changed and when? Can you roll back changes if they didn't work?
    • testing - as for code - can you automate this and make sure the workflow still works and a minor change hasn't broken something else?
    • release - do you have a test environment so that changes can be made offline, tested and then applied to the live environment

These things need to be taken into account when choosing the tool you will be using for your process - what reporting requirements are necessary, are there any licensing implications for test environments?

How to get there
While not part of the traditional definition of SCM, testing is an enabler for an agile SCM environment. Rather than controlling risk by slowing change, you control risk by monitoring the state of your codeline after each change.

Testing and test driven development are not things that happen naturally alas, and the reasons for this could be the subject of another article. Here are some steps that you can take:

    • Make sure that running tests is part of your build (even if tests don't exist yet).
    • Make passing tests part of the criteria for a good build
    • Include code coverage metrics in your build reporting. Consider failing builds if test coverage goes down (which implies that code was added without tests)
    • Start writing tests. (where to start, strategy)

Writing tests where there are none is challenging, but necessary.

About the author

Brad Appleton's picture
Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture
Steve Berczuk

Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Robert Cowham's picture
Robert Cowham

Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.