Thursday, June 6, 2013

Automation vs Product Code - What is the difference?

What are you doing? Do you write code?

That would be one of questions faced by testers who write automation code/script. What is difference?

well, a simple explanation would be automation is interaction between browser, that wont help because most of things a tester uses is based on interaction between two systems. So that what is the difference? Why it is so hard for automation code to run?

Automation code needs 100% code coverage. In other words, each line should work or not to break the flow of the test script. If that happens automation tests become brittle. Compare to product code, coverage is less that 100%. There are figures about 30%,40%  or 80% etc but it always below 100%.

When traditional method of coding is applied to automation, result is endless writing-rewriting of automation scripts. Automation testers end up in a state where they work hard, then work harder but there is no output or useful work is done leading to the conclusion that automation is not going to work.

Another difference is how automation handle the changes in the UI? When there is change in the UI that particular change needs to be handled in the script otherwise test would fail. The question is how product teams handle these kind of changes? If we analyze that, then it is clear that traditional model of code should be applied here too. By separating the UI handles and script flow. (Clue- MVC)

So, we end up using traditional model where we shouldn't using and should use a model that can be easily modified without causing too much trouble.

In Tirukkural , one of oldest books of law, it says that, (my translation)

Doing what shouldn't be done brings bad results
Not doing what should be done brings bad results

There are people tried to solve this dilemma using methods such as BDD or Acceptance testing tools such as fit or Selenese.

Even though, BDD itself is mainly used for product coding, but it fits easily in automation testing. Instead of writing scripts or lines of code, automation testers will write the flow, that will be executed via a framework or by other means. That flow can be understood by developers, marketing people etc.

Apart from using BDD, separating code and ui selectors can make the tests more stable. One can go one step further even separate the data in code too, so code flow, data used for testing, ui element selectors will be in separate places making very easy to write tests, find why tests are brittle. This is needed because by simply using BDD alone can't make the life easier for the testers.


raja's shared items

There was an error in this gadget

My "Testing" Bundle