Because the Agile and DevOps culture is becoming the norm for more and more automation engineers, the need to make our tests maintainable is more critical than ever.
But how do we make our tests more maintainable, and why should we care?
One method was recently brought to my attention by Hung Q. Nguyen from LogiGear. During our TestTalks interview, he outlined an intriguing concept called transferability.
What is Test Automation Transferability?
When creating your tests you must make a clear assumption that they are going to be executed, analyzed and maintained by somebody else.
This is markedly different that it was back in 2000 or so, when I was the only employee who was creating and running my company’s automated tests.
With more and more companies moving towards DevOps continuous delivery type software development practices today, everyone is now responsible for test automation and test management.
As automation engineers we need to adapt this new reality – not fight it.
DevOps World
Back in the day, we had more control and ownership of our test automation scripts. Now when we automate a test, it needs to run against all kinds of environments in our delivery process.
And because of automated CI deployment pipelines we are no longer the ones that determine when and where our tests will run.
But what happens if the tests fail?
Most likely the person or team that needs to figure out what happened is not the same person who created the tests. That’s one of the main challenges we now face as testers.
So how do we create our tests to be more manageable and easier to understand among all the different members of our teams?
Automation is Everybody’s Business
I work for a large organization that has many small teams working across the globe. When our tests run in our continuous integration environments — like when a team checks in code or nightly for our end-to-end tests, I’m not there to triage the failing tests.
Nor is it my responsibility to figure them out. Since automation is part of each team’s DOD, it’s their responsibility — not just the responsibility of the “automation guys” like it was when I was starting out.
Automation Working with Multiple Teams
Nowadays, most of us work with a variety of teams — some offshore, some onshore, some made up of all contractors, etc., and those teams are always changing, with folks leaving and new engineers coming on board.
With all these, changes what should you do with all your tests?
Since many different teams now contribute to the automation effort, no one really knows what all the tests are doing; in fact many teams are afraid to even touch another team’s test.
The bottom line is that you need to start thinking about the transferability of your tests if your company is going to succeed with test automation long term.
Saying is Easier than Doing
Hung and I agree that saying is easier than doing.
Most folks I talk to have found the transformation to this new mode of testing painful.
When I was starting out with test automation, transferability wasn’t something I even considered. If one of my tests failed, I knew what it was doing and how to resolve it since I owned it all.
But the automation world is drastically changing.
We now have to think about how our tests are going to work in a DevOps world. With new development methodologies like containers, we need to also ensure that regardless of the environment or build our tests will be able to run and work with minimal effort.
Harder Since Automation is Fragile
On top of all these changes, we all know that test automation can be fragile.
For example, each time you change an environment your tests might not work anymore. Adding to the complexity is that everyone on the team is responsible for the automated test runs.
So we need to be sure that everyone can understand and analyze our tests, and regardless of who wrote the test, each member of the team needs to be able to maintain it.
This is direction in which automation is currently going.
DevOps and Automation Today
Regardless of whether you're planning to use Selenium, Unified Functional Test, TestArchitect or another tool, you need to start thinking about how your tests are going to be executed, as well as who will be looking at them if they fail.
While you’re creating a test you should ask yourself whether, if you had to maintain the test and knew nothing about it, you would be able to analyze the results and know why it passed or failed. Would you be able to maintain it and fix it even though you didn’t create it?
Test Automation is Development
Hung brought up another great point: 15 or 20 years ago, test engineers could laugh at developers that got beaten up over their code. Since automation engineers were usually lone wolves and owned their code they didn’t have to worry about the standard rigors of software development.
Now that has all changed.
Test automation is software development and should be treated just like any other software project.
If you’re not doing so already, start thinking about your tests and how you can design them better.
Automation is Business
At the end of the day, I believe automation is receiving more scrutiny because more and more people are seeing it as a business benefit.
Companies are now using automation as a business solution to compete in a world that is moving to getting their software in the hands of their users faster and faster.
Think about your automation agile test management projects and your test assets as part of the overall business.
It's not about writing code; it's about the fact that you are now part of the business solution.
