Back to blog

Creating Maintainable Automated Tests - Part 1


For a lot of software, performing maintenance is often more expensive than creating the software in the first place. I believe that this is especially true in automation testing software because even a small change in the main application could cause multiple test failures or a re-write of entire test scenarios.

I personally have spent a lot of time as an automation tester refactoring, re-writing and investigating failures in automated tests. So much so, that

I believe I have spent more time maintaining the existing tests than I have spent creating new tests. To me, this indicates clearly that there is a huge requirement to ensure that software is initially created in the most maintainable way, aiding the people who will be working with it going forward.
This has become more important to me as I have recently become a consultant where I move across various projects providing testing solutions for a range of our clients.

Having tests that are easily maintainable when a new consultant takes over is paramount. Without these, the tests are sure to eventually fail. When the system changes, you will find that you will be unable to maintain the tests easily, and be forced to disable them and continue with (or without!) new tests. Which is something you don’t want.

So, considering this, I decided to outline 5 simple ways in which maintainability can be easily achieved without getting too technical. These might be obvious, but I find that these are some of the most effective ways to achieve maintainability which I have witnessed as sometimes being overlooked.

Team Involvement

A great way to ensure your tests are maintainable is to ensure the whole team is involved in creating the tests. Even better as a consultant, ensure that the client themselves are involved. This can be done at multiple levels, for example;

The product owner and business analysts could be involved in choosing and defining what features they would like covered. The QA team could be involved in designing and writing the tests, the developers could be involved in writing the tests and performing code reviews and the DevOps could be involved in putting these into the CI or CD pipelines.

Having the entire team involved will increase consistency across the entire project. Developers working alongside the QA’s and performing code reviews can ensure that both the tests and the application, follow similar patterns and practices. DevOps will ensure that the test steps in the pipeline are consistent with other steps and artifacts are output to similar locations. BA’s/PO’s can ensure that tests fit with their expectation of how the system works.

All these examples will make the tests and the project more maintainable due to the consistency and team investment. The learning curve when onboarding new people or when handing over to the client is much shorter when everything is working together as seamlessly as possible. Team involvement early on will also reduce the requirement for a handover when someone else takes on maintaining the tests. The entire team is able to help out and the person taking over should already have prior knowledge.

Choose 3rd Party Libraries Wisely

3rd party libraries play a huge part in automated tests. They can completely change the way the entire framework is written. Below I have made a few points on what to consider when choosing which libraries to use:

What libraries do the team/client already use?

If the team already uses some third-party libraries that can solve a problem in the test framework, you should aim to use them. This automatically removes a learning curve for everyone else. You should not pick libraries very few people know about because you think it’s new and interesting. Sticking to well known libraries that the team already know is much more advantageous and makes the process simpler.

Which provide the most readable code?

You should consider how readable your code becomes when using the third-party libraries. For example, I have chosen to use RestSharp instead of using HTTPClient’s previously as the team and I found it to be much more readable and easier to understand. Remember, readability plays a huge part in ensuring tests are maintainable.

Which libraries have the most support?

Take a look at how often the library is updated and whether it has an active community. I would recommend taking a popular library that has consistent support over a new library that isn’t used much and is supported by a handful of people. Choosing less popular and under-supported libraries can result in the library becoming out of date and then your code will have to be refactored once the library is no longer suitable for purpose.

In part 2 of this blog, I will continue the discussion by looking at some programming principles, documentation and test design that will aid in achieving maintainable software tests.

Leave a Reply

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

The browser you're using is out of date. Please update for better security, speed and experience on this site.