Automation Coding Practices to Adopt: Code Like a Developer

With all the coding I’ve done over the years as I write test automation, I’ve come to really appreciate the work that software developers do. Software is complex stuff, and developers have come up with great ways to set standards, share repositories, and review each other’s work 💪

The test automation code we write is important; just as important as the code the software developers are writing. Therefore, we should write our code with the same standards the developers use.  Here are a few suggestions for automation coding practices you should adopt:

Your code should live in the same repository as the developers’ code.

This is for a few reasons: First, the developers’ unit tests reside with the code, so it makes sense to have your integration and UI tests in the same place. Secondly, it’s easier to maintain one repository instead of two; and finally, having your code in the same place serves to remind the whole team that test automation is everyone’s responsibility.

Write clean code.

When I first got started with test automation, I had absolutely no idea what I was doing. All I had was my manual testing experience and a couple of courses in Java and C++.  I did a lot of Googling and a lot of guessing as I put together my first Selenium tests. After much work, they ran and (mostly) passed, but boy, were they lousy! I didn’t know anything about how to write clean code. Fortunately, I had great developers around to teach me how to make my code better.

Here are some of the principles of writing clean code:

• Keep it simple. Always look over your code and ask yourself if there’s a simpler way of doing what it is that you are trying to do. Sometimes the obvious solution to a testing problem only becomes clear after you have solved it in a complicated way; now it’s time to go back and solve it more elegantly.
• Don’t repeat yourself. If there’s something you’re doing in more than one test- for example, logging in to the application- write a method that you can call instead of putting those steps into every test. Similarly, create a file where you save all of your variables and element locators, and have all of your tests refer to that file. That way if a variable or a locator changes, you can make the change in one place rather than several.
• Be consistent. Consistent code is easier to read. Be consistent with your casing: if you have a variable for the user’s first name called “firstName”, don’t make the variable for the user’s last name “LastName”.  Follow the conventions that your developers are using: if they indent with two spaces, you should too. If they put their opening curly braces on a separate line, you should as well.
• Comment your code. It’s not always obvious what test automation code is doing at first glance, and while you might be quite used to the syntax you are using for your tests, your developers might not be familiar with it. Simple comments like “Polling the queue for the delete request” can be really helpful in explaining your intent. Moreover, what might seem really obvious to you now might not be obvious in three months when you need to update the test! Your future self will thank you for the comments you write today.

Solicit feedback. 

Like me, you may not have had a thorough grounding in good coding principles. Some of the best software testers I’ve had the pleasure of working with did not major in Software Engineering. If you did not go through rigorous training in software development, it’s important to get feedback from the developers you work with. On my team, the software testers often review and approve each other’s code, but I also like to have my code checked by developers to make sure I’m not doing anything unusual or creating steps that could possibly result in a race condition.

Test automation helps the whole team by speeding up the feedback process and freeing testers up to do more exploratory testing. We owe it to our whole team to write quality code that is readable, runs quickly and consistently, and provides valuable feedback.

…but TEST like a QA Engineer!

I’m not a stickler for using the right word for testing-related concepts, which is why I use the term “test automation”. But automated testing is really automated checking (here‘s an interesting point of view on that statement). Automated tests serve a very valuable purpose in that they can run regression checks at any hour of any day, without human intervention. But they do not actually test the software.

A sad casualty of the very important move towards test automation is the QA Engineer. Many large software companies don’t employ QA Engineers any more, feeling sure that Software Developers in Test are all that’s needed to validate the quality of their software. And many Software Developers in Test focus solely on the automation, working from acceptance criteria in development stories and looking at the code rather than manually interacting with the software. How is that trend working out for end-users?

Recently, I experienced the following: I received a (legitimate) email that I had some money to accept from PayPal. The email contained a button to click that said: “Accept the Money”. When I clicked it, I got a message that said: “The previous page is sending you to an invalid URL.”

The previous week when I was using a mobile app, a screen that I needed stayed permanently blank. And the week before that, my blogging provider had a page load error when I tried to add an image.

Three weeks, three major companies, three bugs. This is what comes from not employing people who think and act like testers.

It’s true that the whole software development team owns quality, and that quality is everyone’s responsibility. And there are also non-QA people who care deeply about certain areas of an application:

• Developers write unit tests to check the quality of their code.
• Product Owners care about whether the feature does what it’s supposed to.
• UX Designers care about whether the user journey is intuitive.
• Security testers check the software for vulnerabilities.
• Performance engineers care about the response time the application.

But only QA Engineers care so much about the quality of the application that they’ll do things like:

• Type ~!@#$%^&*()-=_+{}|[]\:”;'<>?,./ into every text field to test for invalid character handling.
• Try to purchase -1, 99999999999, 1.3415, and foo of something.
• Enter a birth year of 3019 to see what happens.
• Click every button twice to check for multiple submissions.
• Click the forward and back button on every single page of a website.
• Test 48 different permutations of feature sets to be as thorough as possible.
• Create dozens of test users with many varieties of security settings, to have scenarios ready for testing at a moment’s notice.
• Become an expert on a particular feature and provide documentation and assistance to other testers.
• Test the same thing in the QA environment, the Staging environment, the Demo environment, and the Production environment to make absolutely sure that the feature is working everywhere.
• Test every feature on every supported browser and every supported mobile device.

This is why we need software testers who TEST. We need people who will continually ask themselves “How could we break this?”, “What haven’t we tested yet?”, and “What features will be used with this?”. We need software testers who don’t rush into writing automation without first interacting with a feature. We need software testers who remember that the goal of all their efforts is to have a user who has a positive, bug-free experience.

The software tester of the future is one who thinks about all the features of an application and how they fit together; who understands the needs of the end-user; who can come up with a good testing strategy; and when it’s time to write automated checks, they can do so with high-quality code that is up to the standards of any software developer.