When a person is writing/designing a test case for an automated test, they must think differently than if they were writing the test case for manual execution. Most obvious is the fact that you can give a general instruction to a user, e.g. "Go open a document" and they'll probably know how to do it, and may even know, from context, which document they should open. An automated test script just can't do that.
At the same time, we want our automated tests be more than mechanized humans. They should take advantage of the strength offered by our automated test tool.
What are your suggestions for how you would describe designing a test case for automated tool execution? Here are a few starting points:
- how can I most effectively utilize the computer's ability to execute lots of (possibly repetitive) steps without boredom
- exception handling at many different points in the script must be explicit
- what are the prerequisites (in data or test system configuration) for the test to complete and give accurate results, and how can the test script verify these settings
- If there are multiple possible paths to reach a certain point in the application (e.g. use key strokes Alt-F, O, or choose File | Open...) should the script use a specific path, or randomly pick one of them, or do the test twice to cover both paths?
Re: How is Test Design different for Automated Tests?
Derek, all your points make true sense, but the only suggetion i have is make sure you identify the right resources for Test Automation and believe me there is a big difference between Automation and Manual testers mentally.
I am not saying that manual testers cannot be good Automation resources, becos we all know that is where we started from, but then one of the crtical aspects of automation is extend the tool support to achieve many tasks instead of limiting to features of the tool itself.
Some more aspects for Test Desinging:
Make sure all the data dependancies are taken care and if you need to create fresh data then have a plan for that.
Start with a general exception handling mechanism and then as your continue with scripting you could make them more specific.
Identify or list out what reporting features you need from the your scripts and plan for them accrordingly.
I dont know what framewrok you are following but it really helps when you invest some of your time to design one(of course it is nothing but all your points in one place [img]/images/graemlins/smile.gif[/img] )
Identify the re-usable components.
Identifying the right candidate with the right attitude will help in addressing all your points...