With agile development processes and shorter development cycles, the pace of software development continues to speed up. But how can you make sure that this speed translates to better quality software? This is the challenge facing most software product companies today.

With a four-to-six week development cycle, a software development team that used to produce two or three annual releases now produces between six and eight. But these shorter time frames don't reduce the risk of new functionality impacting existing functionality. In fact, with more frequent releases, there's less time for regression testing.

How do you address this problem?

To keep up with faster development times, you need to make your regression testing faster, too. By automating your testing process, you'll spend less time running regression tests. Learn where to start by asking a few simple questions:

1. "What should we automate?"
   By definition, regression testing is the testing of pre-existing functionality, and with each software release, the set functionality to be tested increases. To stay on top of this ever-growing amount of testing, just divide and conquer. Group all your test cases into the following categories (and if you're missing any of these tests, now is a great time to start putting them together):
   • Sanity tests ensure that your product is put together correctly, and is not missing any major modules or functionality. If your product fails any of these tests, it may not be ready for testing by your quality assurance team.
   • Core product tests confirm that the core product works properly and usually involve testing full business workflows or product feature families. Failure of any core product test means that your product cannot be used by any of your customers.
   • Supporting functionality tests ensure that any remaining untested features (usually supporting features that are used by a subset of your customers) are working correctly.
2. "When should we test?"
   A proper testing schedule leads to earlier identification of any problems with your code. Here's a guide to testing each group:
   • Run sanity tests every time you do a product build, and immediately after you do a product build. Tip: if you have implemented continuous integration, you can run these tests daily, after your nightly build is completed.
   • Run core product tests every time a new build is released to your quality assurance team.
   • Run supporting functionality tests every time a product is released to your customers.
3. "How should we automate?"
   The right automation tool makes a big difference in the efficiency and effectiveness of your regression testing. Any tool you choose should support the following capabilities:
   • Data driven testing offers flexibility to reuse your tests with a variety of data, which means that you can easily simulate a variety of business scenarios. This is especially useful in your core product tests.
   • Headless testing guarantees that your tests are truly automated, and can be run without tying up user resources.
   • Service testing enables testing of software components that lack a user interface. These components (including web services, middleware, and stored procedures) are becoming the de-facto way to build reusable business logic. Your tool must allow you to test these components in a completely automated manner that does not require user intervention.
   • Integration with build and deployment process gives you the highest level of automation. Ideally, your tests should execute automatically every time there is a product build or a product release. The only way this can happen is if your build and deployment utilities are integrated with your test automation tool to initiate the execution of tests and report results.
   • Notification and reporting support available through a dashboard with an up-to-date view of test results, notifications of test failures, and other valuable data.
4. "What will it cost?"
   Expect to provide an up-front investment to automate your regression testing -- both for the tools and the planning and creation of the test cases. (Of course, you'll make that money back in time and manpower savings within a couple of regression test execution cycles.) To keep these costs as low as possible, pursue free or low-cost alternatives to the expensive licensed automation tools from big software vendors. Open source or free software from QA service providers may not make a pretty software sales presentation, but they're more than capable of supporting your automation tasks.

As software development continues to speed up, regression testing will continue to gain importance. Adopt it today, and you'll be better prepared for the future.

» Need more guidance in automating your regression testing? See how Tripod can help you.

Download our free reports:
» How To Build Quality Software -- Without Breaking The Bank
» Capital Efficiency 101
» 5.5 Ways To Make Sure Your Software Development Project Is Under Budget