A tale of two styles

[giuseppe.lacagnina]

Hi everyone.

I have a problem for which I could think of several solutions. However, I would like to know peoples' opinions on what would the best solution be.

I am testing a web application with Ranorex. This web application comes essentially with two "styles", which are basically two versions of the same thing. They differ in colors, fonts and, more to the point, in the disposition of some elements. Fortunately, the elements which have different positions in the two styles are not many. On the other hand, there is no real guarantee that this will not change somehow in the future.

For the moment, I focused on testing one style only, and I have a good, complete repository. What I need to figure out is how to reuse most (if not all!) the existing test cases without having to rewrite much.

My first idea was to change to C# the operations involving the elements not in common between the two styles. I would add a global parameter indicating the style and the C# codes would, based on its value, pick different items and perform the same original operations. There would be some new items in the repository of course. How does that sound?

Thanks in advance!

[krstcs]

From what I'm reading, you have objects that perform the same function, but are different in location (different parent objects, etc.) or in name.

You idea sounds like it would work, but it could get cumbersome if there are more dissimilar objects added in the future.

Do your objects have unique ids? If so, that is the easiest way to handle this. Just make your XPath use the unique id and don't worry about where it may be.

For example:

If you have a button 'ButtonA' on both versions of your site, and ButtonA has an id='ButtonA' on both versions, then you could use the following XPath on both to find the object:

//button[#'ButtonA']

The '//' says look everywhere. The '#' says this is a unique id on the page, so Ranorex can use a hash search to find it, which is very fast.

The XPath above is equivalent to "//button[@id='ButtonA']. The difference is that the second version here will search EVERY PATH until if finds an item with the id of 'ButtonA', while the first one above would essentially go straight to the button.


If your objects DON'T have unique ids, I would ask your devs to start using them in order to help you with test automation. If they care about making a great product, they will do everything they can to help because the more automation you can do, the quicker they know what's wrong.

If they won't, or can't (due to coding styles or framework), then your option of making code modules and passing in a global parameter would work.

[giuseppe.lacagnina]

Thanks!

What you say makes perfect sense. I will push the developers to give unique IDs wherever possible.

I was also afraid that addressing items like this might lead to performance issues. On the other hand, I could rework my repository by identifying some important elements by ID and giving the sub-elements relative paths: can I do something like

//div[#'mainDiv]//a[@class='myClass']

?

would it work and be more efficient than straight

//a[@class='myClass']

?

[krstcs]

Yeah, it should be. Any time you can use a unique id, it is faster and more accurate. It should be the first thing you look for when mapping out elements.


ETA: Remember you can always try anything out by creating a new repo item with the same path and then changing it to see if it still works. This won't hurt the original and will let you see what you can "get away" with...

[giuseppe.lacagnina]

Right you are! Thanks again!

[krstcs]

You're welcome!

[lucian.teodorescu]

Hi,

Depending on the level granted to source code, you can also work with tags. I find this easier and I will explain why: I add tags like "qa_ID_Like_Name" to items that I am interested in. When changes are made by developers, they might Copy-Paste some code and also change the ID or the Class name used. But I've told them that 'my tag', which is also in the copied code, should be preserved 'as it is' whenever they use a different version of a function.

And yes, I usually combine IDs, Class names and tags.

[giuseppe.lacagnina]

Thanks! Sounds very interesting. I will coordinate with the developers.

[krstcs]

Unless you are in a very, very small shop (<5 people), testers should NEVER, EVER touch the code they are testing against! It is a conflict of interests, and in many cases, will cause auditors to write you up and not verify your software development practices as valid! If you are required to be PCI (Payment Card Industry) compliant, this will cause the PCI auditors to fail you and you won't be able to accept credit/debit cards until you stop doing it and account for all code changes.

Please, do not do it!

If you developers are willing to work with you, then you should have them put the changes in along with a valid story that can be tracked/tested against the changes made.

[giuseppe.lacagnina]

Do not worry, of course I am not going to touch any code! I am not out of my mind yet
I just will ask the developers to provide some IDs to help identify web elements in Ranorex.

[krstcs]

Yeah, that wasn't really aimed at you Giuseppe.

[lucian.teodorescu]

Thanks Kelly for your valuable input. I will definitely consider it. Still, we are in that small shop and have all the certifications we need. So far so good. As for code changes, everything is on TFS.
And yes, I am in a 'dream team' so as I asked the developers to put IDs, and they do it now, I will ask for tags also, when needed.

Thank you again.

[giuseppe.lacagnina]

[krstcs]

That is awesome Lucian! I was on one of those back 15 years ago when I started automation, it is SOOO nice.

But, my team now is awesome as well, even though we have 50 devs and 5 different teams. Every one of them WANTS automation to work well, so they bend over backwards to make sure the 3 automation team members get what we need.

And, my point was more for those that aren't in these great teams, to make sure that none of us go down a path that will get any of us in trouble.

Happy testing!!