Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
Yes, there are ways to automate regression testing and it should be automated. Web services lend themselves to automation because of the absence of a user interface – a component which has traditionally made automated regression testing difficult. There are vendors who offer regression test automation technologies that can be found with Web search. The components and aspects that you would need to consider are:
1) Automated build process. The services would need to compile and deploy automatically. This is typically done on a daily basis by the build system (at night) after code changes were made during the day.
2) Tools that allow you to easily create test cases that are as close to the use case scenarios as possible, and at the messaging layer.
3) An infrastructure for running the tests automatically after the build is made.
4) An infrastructure for making the test cases available and sharable between different teams (development, QA, etc.) so they can collaborate efficiently.
5) Consolidated reports with the results so there is no repetitive time spent checking on test execution results.
6) Ability to link tests to requirements in the requirements management system or bug IDs in the bug tracking system becomes very useful in tracking progress and identifying what is tested/not tested, what is working and what is not working in a project.
This way you can build an efficient agile process. Every day developers and QA engineers can come in the morning, check the test execution results, resolve any regressions, then go on coding and creating tests for new features with confidence that existing functionality is still working correctly. Efforts are spent on creating the tests for new features, not testing old things or running tests manually, and this is a huge productivity gain. The regression test set grows as a valuable asset that can be executed at anytime to verify the application and it allows you to progress with the project with predictability and status awareness, rather than receiving bad surprises towards the end. This is all very doable and I've observed many organizations apply this process successfully.
This was first published in May 2007
