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.
[Hall of Fame]
Please consider giving a Kudo if I write good stuff
Why automate? I do automated testing because there's only so much a human being can do and remain healthy. Sleep is a requirement. So, while people sleep, automation that I create does what I've described above in order to make sure that nothing gets past the final defense of the testing group.
I love good food, good books, good friends, and good fun.
Mysterious Gremlin Master
Vegas Thrill Rider
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.
[Community Heroes] are not employed by SmartBear Software but
are just volunteers who have some experience with the tools by SmartBear Software
and a desire to help others. Posts made by [Community Heroes]
may differ from the official policies of SmartBear Software and should be treated
as the own private opinion of their authors and under no circumstances as an
official answer from SmartBear Software.
The [Community Hero] signature is used with permission by SmartBear Software.
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