About efficiency in test-automation

Leave a comment

6. November 2012 by Michael Wowro

With GUI-based test-automation (e.g. with Selenium) you establish a system of checkpoints (=testcases/ =scenarios (in terms of gherkin)) for the functionality of the software. The functionality is a set of features. Features have 0..n checkpoints. Beside the system as a whole, every checkpoint is ressource-consuming. That’s because you have to establish and maintain them – the latter in case of the feature changing. Hence the checkpoints shouldn’t be uniformly-distributed over the software for logical reasons. There are 3 main criteria for deciding about the density of checkpoints and which influence the efficiency of your test-automation efforts:
1.) criticality of the feature: How important is the feature for the over-all-functionality of the software – ask the manager!
2.) fragility of the feature: How frequently bugs have appeared in relationship with the feature in the near past – ask the developer!
3.) persistence of the feature: How probable are changes to the feature in the near future and as a consequence a ressource-consuming maintenance – ask the manager!
With these criteria you can make a lightweight plan, where to start the test-automation.
Over the time you add more and more checkpoints as new features come and as you learn about the “organism” of the software.
Learning should result in heuristic rules like “make a new checkpoint for every new bug”.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: