Today, automated test builds are a goal of most development shops, and Martin Fowler’s article on Continuous Integration provides an excellent overview about the major aspects. Regardless of where your team is on the path to achieving this goal, here are a few hints how to ease your way.
The committer pulls test coverage out of the team
At the start, your test coverage will be somewhere between nothing and miserable. But, remember, you already have an ace up your sleeve. That’s right, put the "Committer" to work enforcing test coverage for every bug fix and new, complex code changes. Bug fixes are exceptionally interesting code changes. First, they show a place in the code that’s actually used by customers! This is really important information if you know that only about 30% of your code base will really ever get used. Additionally, it makes a lot of sense to write a test for this piece of code (would have made more sense to do it for the initial release, but baby steps to success) as it broke already once. As for complex code changes, I’m talking about things like nested if declarations – these are usually ugly to read (and harder to understand) so why not just enforce test coverage for them.
Automate test runs and send reports to everyone
Ok, now that you have a couple testing standards in place, here comes the tricky part. Wouldn’t it be great if your committer could spend his time reviewing the growing mountain of merge requests instead of spending all that time running tests? What we’re talking about is a Continuous Integration server (ala CruiseControl) to handle all these menial tasks. You can easily configure these systems to check out a clean build of your code after a commit, run through all the automated tests and send an email notification whether or not there were any problems (and at the start be prepared to be overwhelmed with problems) including personalized blame emails to the last committer who broke the build.
Continuously improve code quality
Once you have this up and running, you can branch out a bit. Interested in analyzing your code base for common error or bug patterns? Depending on your development platform, there are many tools available. The important thing is showing your team that code quality counts, and that you are willing to invest extra time and effort in improving the current status. This changes the entire development atmosphere at work because everyone knows that they have to start taking their job seriously in order to become professional software developers.
Manual smoke tests for critical, untested code
Meanwhile, while working on increasing your test coverage what do you do about those obviously, gaping holes? Larger refactorings to your website, like architecture changes or critical, 3rd party library updates, should be covered with a "smoke test". With a module-wise list of business-critical website functionality, you need to get the team to manually test those features not covered by automated tests. Forcing the whole team to do this not only increases the likelihood of finding a bug, but it creates tremendous pull to get this list of features under automated testing as soon as possible!
Agile Web Operations 