Test automation and coding standards

Publish date:

Test automation is a type of testing we can’t go without anymore; especially in Agile teams it has become a must.

When large vendor tools are being used, you are usually forced into a specific way of working and architecture. This article is more on the other tools such as open source. Most of the available open-source tools are more framework than actual, complete tools—for example Selenium Webdriver and Cucumber. On their own you can’t get a test up and running. They are like the tires on a car; without them you can’t drive but having only the tires and not the other parts, you can’t transport. To be able to combine these frameworks in a proper “car” programming is needed. However testers are often not schooled in programming. This could result in bad coding of the framework, which will eventually result in a maintenance hell. So why not treat test automation code the same as the code of the developers? One of the major benefits in this method is the normalization of the code. A developer can review testing code and maybe the tester can even review the development code. A second benefit is the maintainability of the framework as all team members know the way of working. This makes it even easier to create a more integrated framework in the team and make it a joint effort between developers and testers. They both benefit from a properly coded framework.

Another item to address is testing the framework with unit test. Testers make mistakes, and when they are programming that chance of making an error may increase. Therefore the framework on which the tester is building should not contain errors or mistakes, as a failed test could mean a bug in the code or a bug in the testing framework. By using unit tests on the testing framework, more trust can be placed in the testing framework and a discovered bug is more likely to originate in the application code. This is often seen as “who tests the tester,” but I do not agree with this assessment. A test automation framework is code written by a human being, and normally we call a human being that writes code a developer. Code written by a developer has to be tested. So why is an automation framework written by a tester any different?

Reference: https://www.joecolantonio.com/2017/06/29/selenium-like-goodyear-tire/

Related Posts


A journey of a thousand miles begins with a single step

Lee Beardmore
June 26, 2018
Focusing on the little things in a business process transformation journey can make the biggest difference.

Why competitiveness means keeping pace with the cloud

Charlie Li
June 25, 2018
For companies with traditional IT estates made up of cloud and legacy (on-premises) apps and infrastructure, matching the development quality and velocity of cloud-native startups remains an ongoing challenge. But by automating IT operations processes with cloud technologies, they can begin to bridge that gap.

Watching the finance automation “Masters”

Carole Murphy
June 19, 2018
“Masters’” expectations of what they can achieve with automation are higher than those of their less advanced peers, or “Novices.”

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.


Close cookie information