Testing and Scrum

There is a small problem with Scrum when it comes to testing when a full complement of tests takes a long time. In wireless products a full set of tests can take weeks and even what you would call release tests can take days. This of course doesn't lend well to the concept of Continuous Integration when you can't run your tests even nightly, never mind after every commit. On the other hand you don't want to allow untested code to your code repository trunk so what to do?

Here's my idea, pulled from the way many Linux components do it. It assumes a version control system with fast branching and merging, incidentally Git fits this very well. The idea is to have the tree trunk as your "unstable" version. Code going to the unstable undergoes a test set that can be run quickly. When ever a release is needed / wanted, a testing branch is created. This version undergoes heavy testing and, if needed, small patches can be applied directly to this version instead of going through the unstable. If many changes are required, it's probably better to scratch this version. This shouldn't happen often if unstable testing is decent enough. But when tests pass, a stable version is created and the patches are merged back to the trunk.

This way the developers don't need to worry about anything but the trunk (of course they should still use branches when developing new features) and new features can be integrated all the time full-filling the Continuous Integration idea and staying flexible while still having the extra layer of testing required before releases are made. This creates the minimum possible amount of overhead while keeping things safe. The following figure illustrates this idea: