BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Starting Test Automation for a Legacy Project

by Vikas Hazrati on Jan 25, 2011 |

It is always a herculean task to write automated regression tests for a legacy application. The questions vary from where to start, how much to automate and deciding on the best strategy for automation.

Responding to a thread started by Mark Levison on the Agile software testing group, Hubert Matthews suggested that the approach that he recommends is a risk based approach.

You can never test everything so you have to choose where you want to spend your time and money. Testing for me is primarily about information and risk and not about blanket coverage or completeness.

Hubert mentioned questions which help evaluate the areas to focus on. Some of his suggested questions include,

  • Where is the client currently experiencing the poorest quality?
  • What are the key areas of functionality (e.g. what makes them money)?
  • Would the client prefer more features to better quality?
  • What are the biggest risks to their systems?
  • If the client could improve one thing what would it be?
  • Would exploratory manual testing find more important bugs?

Rakesh Patel suggested a similar approach when he mentioned,

  1. Only automate through the GUI the most important paths through your app. A lot of apps have some common path that is used in 80% of cases. If this stops working, your business is in trouble!!
  2. If you can bypass the GUI and go straight to the backend to test business functionality, do that. That means GUI-specific integration tests are about making sure the data from the front-end get to the back end.

Mark Fink suggested that before starting on automation for a legacy project, he likes to get a big picture of the project to identify the specific areas which need attention. He suggested a list of tools which are helpful in getting to the big picture. Likewise, Nat suggested that the key is to build end to end tests for the area that you want to focus on. He recommended that for a legacy system, if there are manual tests, then usually those are scripted well enough to become low hanging fruit for automation.

Ralph Bohnet and Gerard Meszaros talked about test driven porting and one of their conclusions was that for any legacy application, the most critical business scenarios should have automated regression tests if the porting has to be successful.

Lisa Crispin agreed that there is a little chance to automate the entire legacy application in one go. What worked for Lisa was a combination of factors. Some of which were,

  • Ask the customers to prioritize the critical areas of the app
  • Write manual regression test scripts for each area
  • Budget time in each sprint to write GUI smoke tests for those areas
  • Execute the test suite at least once a day with the CI framework
  • All new development should have adequate tests

According to Lisa, with this approach, they could adequately automate their legacy application within a period of 8 months.

Thus, it might be a far call and a time consuming affair to get the entire legacy application covered with automated regression tests. The suggested approach is to build enough coverage for the business critical functionality and gradually build a harness around the system.

Related post on InfoQ : Testing Techniques for Applications With Zero Tests

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

From legacy to test automation, and then back to legacy by Olivier Gourment

Thanks for the interesting overview of strategies to prioritize and incrementally raise the test coverage. We've also successfully added functional tests to a large legacy application using those strategies (cover the critical business cases).

The problem comes afterwards. If some developers in the maintenance team don't understand why tests are important, you can be sure the former-legacy project will become legacy soon after the consultants have left the building.

In other words, sensitization and training MUST be part of the strategy. And this takes a lot of effort since the team has to be able to understand and formulate in their own "words" why tests must become part of the standard development going forward.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT