We had an interesting discussion at work today about the nature of test automation. This discussion stemmed from a need to provide a fast, automated means of generating data to satisfy testing scenarios at my place of employment.
Basically, our manual testers generate data necessary for testing every time they want to run a test. In order to complete a short test (<5 minutes), 10 or 15 minutes must be expended. The acceptance criteria for any given test varies greatly from test to test, and often, the criteria is more ad hoc and difficult (or impossible) to express in a way that we can automate easily.
One theory is that test automation is strictly that: testing automated. If I write a line of code, that code should be in support of testing a set of criteria and producing a pass/fail result.
I totally disagree. Test automation is simply automation in support of testing. It doesn't necessarily generate a pass/fail result, but might ease the burden of a manual tester trying to achieve one. If I create an interface to allow a manual tester to build sets of test data quickly, and then produce an automated process that will pickup that data and do work, this, too, is test automation. So, any code written to simplify and make more efficient the overall testing effort must be test automation.
Part of my reason for approaching automation as a development project rather than simply testing is so I can think more of the box.
For example, I am about to begin work on just such an interface..in .Net, not QTP. My estimate is that it will allow a user to create useable data sets in a 10th of the time it would have taken before, as it will support templates, iterations, and can be extended to add tools (such as generating a set of data for all states, etc) very easily.
posted @ Thursday, June 12, 2008 8:42 PM