Rules Every Tester Wants Developers To Follow

Was working on a project where every other checkin would break some test, and it wasn’t because of bugs.

Test where failing because of changes to UX, element id’s, paths, etc.

Could feel that people where losing confidence in our automated testing.

I use to feel like some software developers where trying to make me look bad.

That was all in my head and not completely true.

I still want to work with people who help me do the best job. Might sounds a little selfish, but it’s true.

A] Write Unit Test

It’s a very strong first line of defense. Who wants to be the second line of defense when the first line surrenders without a fight? I sure don’t.

B] Run Smoke Test Before Checking In Code

Number one pet peeve – Being handed a peice of software that clearly doesn’t work at all.

C] Add unique ID’s to Important UI Elements

Makes it a lot easier to automate because you don’t have to write complex CSS or XPath to select elements. There’s also a speed increase from being able to search & find elements by ID.

D] Names & ID’s Should Be Human Friendly

userName is a lot better then input123 More points on human readbility

E] Give Testers a Heads Up Before Major Changes

Save the QA teams time trying to figure out why test are failing, only to find that it was because of a system change.

F] Favor standard Web Elements

use < input > over < div > for HTML tags

G] Repeat Class Names & Other Attributes ONLY If They Make Sense

Do you really think
should have the same class name? 99% of the time they shouldn’t.

H] Help Avoid The AJAX Sandwich

If the page is loaded with AJAX help QA out by writing a “test hook” that will let them now that loading is completely done.

I] Avoid Telerik controls

Trust Me Don’t Do It. Telerik custom controls don’t play well with others. Maybe in the future they will change but for now it’s better to just avoid it.

J] Avoid Nesting iFrames

Selenium struggles with nested iFrames so you would save a lot of headache by only using them as a final option.

K] No Compound Class Names Example: (e.g. classname=”classPart1 classpart2” ) – Selenium doesn’t play friendly with them.

Most of the rules can be implemented with little change to development. In the end most of these boil down to a lack of communication. We all just want to be understood.

One response to “Rules Every Tester Wants Developers To Follow”

  1. […] Changing the UI to include appropriate attributes, and ID’s helps decrease brittleness. Checkout rules “C”, & “D” for Developers from Testers. For testers careful attention your element locator strategy is just as important (pro tip: Use […]

Leave a Reply

Your email address will not be published. Required fields are marked *