The tips before starting huge project

Ask general questions here.
Posts: 8
Joined: Tue Feb 03, 2015 7:57 am

The tips before starting huge project

Post by huzunkaya » Tue Mar 10, 2015 2:48 pm

Hi everybody,

My company just had an agreement with a bank and as they told there are more 2000+ Test Cases.
I recently completed a project having 100-120 Test Cases and learn somethings from my mistakes but instead of these, i want to listen others experienced people opinions to share their tips here.

I had 2 serious problem , first one was that i was coding my test cases on a url starting "" then it changed "", when i changed the domain, but ranorex can not find some object so i rearrange all xpaths from beginning, it took my 4 days, now im simplifying xpath from beginning to have elasticity.

Second was about what to do about failure.Test Cases was related each other. if one of fails,others fails automatically too.i wrote some codes if upper cases fail,run these records etc.

So if someones had experience and tell us how to solve them, i think it will be helpful for everybody,

Best Regards.

Certified Professional
Certified Professional
Posts: 12
Joined: Thu Mar 05, 2015 4:33 pm
Location: New Brunswick, Canada

Re: The tips before starting huge project

Post by Benwa » Thu Mar 12, 2015 7:43 pm

Hi there,

I'm actually helping out a bank with their automation currently. They have over 5,000 manual test cases, but we are picking the best candidates for automation.

I'll suggest making your xpaths as robust as you can. I know for me, it's been the #1 reason for my issues due to the application being a Flash application that's ran in IE8. It has a lot of generated code and causes some of my repo items to not be found because instead of being at Div[4] like the last run I did, it's now at Div[2] on my latest run because of the generated code. Or the iFrames will have generated ID's. Here's hoping your application won't be as bad as this one :)

As for your 2 serious problems, create a variable for your domain. Create a data binding with your domain in it, so if it ever changes, you only have to change it in that one spot.
As for failures, maybe change your Error Behavior to continue with sibling, or iteration so that you don't skip so many of your TC's.

We use a lot of data bindings so that we don't have to change a lot of the code or recordings. Makes things a lot easier to manage as well. Last but not least, try to keep your repository and your test suite well organised so that you can find things easily enough and don't have to search for a very long time.