Aberro Software recently released a new testing product called AberroTest, which aims to make it easier to create and use functional tests. Steve Lafferty, VP of Marketing at Aberro, described the problem their tool is attempting to address in this way:

Traditionally, test automation tools have been used for regression testing. That's because they have been unable to keep up with rate of change in new product development. Automated testing tools have been useful when the application is stable, but that's not the time you really need to be testing it. The time you want to be testing it is when the application is changing, when a lot of innovation is going on.

In other words, the difficulty with using automated functional test scripts while the application is under intense development, according to Lafferty, is that the constant changes keep breaking the test scripts. Aberro Software has attempted to address this problem, thereby making it easier to do functional testing earlier in the development lifecycle. The way they address it is by replacing writing the script with a "map," created via this three-step process:

1. AbberoTest scans your application (either a web or a Windows application), and locates all "control points." A control point is any control by which a user can interact with the application, such as a tab, a text field, or a combo box. They then save a list of these points to a map file, which represents a map of all the ways in which a user or client may interact with your application.
2. You, using a framework they provide, attach reasonable test data for each of these control points. This information also gets saved in the map.
3. You specify verification rules, such as a rule that says that any order over $50 should get free shipping. The verification rules also get saved in the map.

When you then run the actual test, AberroTest looks to see what control has focus initially, checks the map, and decides what kind of interaction to do. The tool performs the interaction, then checks any relevant verification rules. Then it tells the application to advance. It essentially follows the tab sequence in the application. Steve Lafferty called this following the application's "natural navigation".

They provide coverage analysis so you can see if areas are being missed. If so you can direct the tool to go to places that get missed by its default navigation. However, the main point of this approach is to enable the automated functional test to be resilient to change. If you remove an entire control, you don't break a test script. Since the control is no longer part of the UI, the tool won't attempt to interact with it. Moreover, as new controls are added to the application, they will be discovered by subsequent test runs and added to the map. You can then configure test data and verification rules for the new controls.

What do you think of this approach to automating software testing?