We'll buy an automatic testing tool before the end of this year and we're looking for the best way to maintain our scripts. I think that each of you had, one day, thought about that...
In fact, what we'll do (we develop an ERP), is to define some "transversal block". Vertically, there'll be each of our customer xith his data, his configuration,...
And horizontally, we want to put these common blocks.
1 - the GUI Map.
2 - Recovery Scenario.
3 - Checkpoint, synchronization,...
4 - Functions generated
5 - Data Driven
What about you? Did you think about this in a different way?
Please give advices and remarks.
The biggest problem I have encountered in script maintenance is that the test repository is not thought out before something is implemented. What I mean is that people start producing many scripts and don't consider the fact that many of the things performed in scripts is repeatable and reusable. You should first determine what functions can be reused and then develop scripts to act like functions. Scripting can be easily maintainable if we think about using the same methodologies used in OO. Make a lot a small scripts and put them together by using calls in main scripts. That allows you to maintain fewer scripts but with a lot of functionality in them.
Data driven is by far the best way to ease the problem of proliferation of scripts and make them much more flexible and maintainable.
Before choosing to purchase a tool to create automated test scripts do a complete evaluation of what you will need the tool to do and if it can reuse the manual scripts you have been using to date.
Remember that automated scripting can get you into problems faster than you ever could with manual testing.
Script maintenance is a big problem for both us testers and management. I know of an automated tool that will greatly assist in script maintenance.
Changes in the application are why we exist but this tool called Certify from Worksoft uses a relational database and can detect changes in the GUI of an application and can render an Impact Analysis report of what has GUI elemenst have changed as well as which test scripts (down to exact row) need to be updated.
Well..as a side note - yes QTPro - will automatically change field refs if you update the OR, and if you do the update properly in WR you don't need to update your scripts. Planning up front is all you need. But it is true that we don't plan like we should and this capability is nice, but it's not rocket science earth shattering stuff either - heck the gui is a text file - so is your script - once you are aware of what you updated (changed) in the GUI Map/Object Repository - simply do a Search and Replace in your (hopefully shared) test directory (s) through Unix or even Microsoft.
Well...Without speak about something particular, I saw really interesting paper about these subject (one is called "improving the maintainability of Automated Suites" by Cem Kaner) and I would like to know what you think about Data-Driven approach and Framework-driven approach.
Do you use your tool with one of these approach? Both?