Reducing time of test maintanence
I'm wondering what are your solutions/tips to reduce test maintenance time ? What's your experience in that area ?
Forum Discussion
3 Replies
1) Modularize your code some how... the less repeated code, the easier it is to maintain. If something changes in the AUT, if your code is sufficiently modularized, you only need to edit one or two places rather than in each test case.
2) Work with your developers directly to find ways of creating reliable object identification mapping. One of the biggest headaches, regardless of the tool, is when the component identification properties change and you need to re-do the object identification. If you can have your developer give you reliable ID's and such in your components, you can then use them in your mapping which would make your life a WHOLE lot easier.
3) Data drive your stuff. There are two layers to any test case... the actions to be performed against the application and the data that is used within those actions. Sometimes the actions themselves are the data. So, if you can extract the data layer from the code layer, when you need to maintain your tests, you may find you only need to update data and not the actual code.
These are just 3 items that I've found over the years that can help with test maintenance. Note that, especially with regards to #1, this completely eliminates record/playback as a reliable means of automating tests.
1) This goes along with modularizing, really, but don't hard code anything in the tests. A path or some other value will change and you'll forget to update it and the test will crash and you'll have to debug till you can find it.
2) Keep any base reports, data documents, or any other documents you need to refer to in the tests in a folder inside the TestComplete folder. TC knows the Project Path and you can find anything you need to reference that way. Nothing gets left behind on a local drive this way.
3) Use some sort of version control to keep track of your project, even if you are the only one working on it. You want to be able to save your work in a safe place and retrieve it if necessary.
to add to Marsha_R & tristaanogre
In my case I keep layers of scripts.
for eg to interact with GUI I have separate layer and test steps to interact with data in separate layer.
so ones GUI changes I have to only change GUI interaction layer
If need a new test using same GUI can re-use GUI interaction layer
It's not TDD but bit close to that concept...
different environment (for eg test running machines) have different speeds.
Your waiting time for objects should be planed and suits for slower environment still run faster in others.
Always do mapping manually , select properties carefully.
Get to know best practice of your selected language and better if you know bit of project management.
(test automation is a software project it self)
test should be as much as independent. If test A fails still you may need to run test B.
(think of senarion, if test A fails all the test from B..to Z fails )
use KISS philosophy
If you can use test management tool that also would be help if testes are going to grow.
always think in long term perspective, most automation would need some time to return the investment.
Also I recommend to read ISTQB documents if you have enough time
