|
More often than not, I have seen people going for test automation just because they want to go for this exciting buzzword. It is generally realized in the very end that automation has not given intended returns.I would suggest that before even thinking of Automation a thorough study of your application/system/module should be performed.
The following types of test cases are preferred (but not limited to) choice for automation:
Tests that need to run for every build.
Tests that use multiple data values for same action.
Identical tests that need to be executed using different browsers
The following types are not considered to be the good candidates for automation:
Test Cases that will only be executed once.
Test Cases used for Ad-hoc/random Testing.
Test Cases that are infrequently selected for execution.
Test Cases that will require manual intervention ie a task not possible to automate.
The most imp. one--based on the intuition and knowledge of application. Eg. if you find that you cannot escape from manual intervention.
Above all the effort required to develop and maintain the automated scripts should be weighed against the resources (no of hours, budget) that task would take while manual execution. The amount of changes the application undergoes from one build to another should also be taken into account while choosing for test automation.
If an app undergoes drastic changes that means most time will be exhausted in maintaining the scripts. These apps are then considered bad choice for automation.
Considering the above points Return On Investment (ROI) should be calculated and this should be the single most important criterion while going for Test Automation. |
|