The end of 2022 marked a decade since I left university. Having spent the majority of that time working in test automation I felt it was a good time for me to look back and highlight some of the keys takeaways with regards to starting and maintaining a good level of test automation within a team or organisation.
I will be going over some of the things I feel have been vital in my own personal automation journey, as well as some things I may have done differently, given the chance. I’ll round up with a few key points on where I see test automation in the near future.
Automation in Agile development
Application development using an Agile framework is now pretty much the standard. One of, if not the most critical aspects of agile is fast feedback. Continuous Integration is one of the most effective ways to provide such feedback. One of the most important aspects of continuous integration is test automation. In a sense, attempting to be Agile whilst ignoring Test Automation would be a futile endeavour.
This is very good news for automation testers as it puts us in the driving seat, given you have the right skill set. Where even 10 years ago test automation could have been seen as a luxury, it’s now widely regarded as a necessity. We should be using that to our advantage by ensuring we are ready to embrace this challenge.
Skills
The ability to code is an undeniable requirement when talking about the skill required to be an automation tester. although being able to program is vital, there are other key skills required. There is often a misconception that automation testers are failed developers, it’s an idea that even I believed early on in my journey and if an automation tester only writes code then that may well be the case. I have found in order to truly offer value and develop in my role I have had to broaden my skillset
There was a period a few years ago when I felt my development skills were in line with the market but my testing skills were getting left behind. This was a time of reflection for me where I had to actually focus on the so-called ‘less technical’ sides of testing. This journey actually helped me to become a better test developer as it greatly helped with my ability to design tests and see the bigger picture.
Unfortunately, with the rise and undeniable importance of test automation, I feel we may lose or fail to develop the aspects of a tester that we took for granted many years ago.
Relationship with developers
The importance of building a good working relationship with the developers in the team can not be stressed highly enough. It’s not to say test automation will fail with a not-so-good relationship but automation will be much harder and less successful.
Building a good relationship doesn’t just mean going to lunch with them, it also means building a positive working relationship with them. Most developers now appreciate the importance of test automation but if not, it’s key that the benefits to them are highlighted, such as quicker feedback etc. Getting the developers to design the application with test automation in mind is one of the prime benefits of such a relationship.
Often simply asking for their opinion on the code you have written can help them to develop positive ownership of the test process, developers like to talk code so it’s a good idea to use that to your advantage. This process of pairing with a developer to write test code has at times helped me to produce my best work.
Planning, Scope and Expectation
The success of any Test automation effort, like most endeavours, is judged on results. A simpler test automation framework that quickly delivers results will provide more value than a polished framework that takes longer to develop than the application it’s supposed to be testing
A well-planned automation effort will help you to focus on what’s important early on, but should also allow you to think about what’s to come and how to improve. Planning should also allow for time to experiment and refactor.
Be clear with your expectations for what can be achieved within given timescales whilst also being clear about the possibility that things can change if problems arise, this can work both ways, something that you may have expected to take days sometimes only takes a few hours but it can often also occur the other way round.
Tools
in my 10 years working as a test developer, I have used a number of test automation tools, some open source, whilst others proprietary.
Having said that, for my own personal development I have always focused on going as low level as I can. This means I would always initially attempt to build an automation framework using open-source programming libraries. From my experience, this is the best way to broaden your skillset. This way I feel I have never really had any issues switching tools or even switching programming languages.
There are other tools such as Postman and Jira that remain extremely relevant regardless of whether you are spending more or less of your time writing automated tests. Click here to go to my post covering some of the key tools required in order to survive and prosper as a tester, automation or not
Automation Standards
It can often be fairly straightforward to patch something together in most programming languages that are able to perform some form of automation, for me, this was a good thing as it allowed me to see results fairly quickly. My first few frameworks followed hardly any basic programming principles, which may have been fine as I was the only person using the application to speed up the testing. This approach simply did not work as test automation was scaled out with larger test teams and larger projects.
The good thing for us is that a lot of clever people have already outlined a good number of standards that we can adopt in order to make everything more effective and efficient. There are some standards that apply more to automation but the majority of them apply to the general art of good programming
following good programming principles will massively improve your ability to write good reusable, extendable tests
This has been an obsession of mine over the last few years. See my blog which covers some of the aspects I feel extremely strongly about with regard to automation standards.
Reusability & Documentation
It has felt like an obsession at times to produce the most complicated and technically impressive test frameworks known to man, at the time just to prove my worth, only to look back at the code 20 minutes later and have no idea how it works. Your test code is more likely to be judged and used by other testers, who don’t necessarily think like developers They would expect the tests to tell a journey, and dense overly complicated code does not always do that.
Selling the idea of test automation is also something you need to consider, you might be sold on the idea, and the devs might, but it’s likely someone in the team is not. I’ve found spending the time to produce good reports or giving a general idea of the ROI (time savings etc) can go a long way to getting your work recognised and adopted.
Deciding What to Automate
In attempting to prove my value as a legitimate Test developer I would often automate everything that I could, regardless of the value that it actually provided. I felt the more test I wrote, the more code I had, and the more I had to show for my efforts. This was ineffective for many reasons with the two biggest issues being the following:
- Producing tests that provided little to no value
- Not spending enough time on tests that were more complex, took longer but provided more value
Using the Test automation pyramid is a good place to start, prescribing that the number of tests decreases as we move from Unit to Integration to feature tests.
The focus must be on the creation of high-value tests, with the focus being business-critical areas as well as those with the highest potential for failure. The focus will then move to areas that will save the most time as well as areas where you may be able to eliminate the potential for human error.
Conclusion
The case for test automation gets stronger as each day passes. As systems get larger, and more complicated and feedback cycles get shorter, the idea of automation as a luxury is slowly drifting into the distance.
As test automation transitions from luxury to necessity, the standards inevitably increase. The level of scrutiny aimed at the efforts of those building such applications will also increase. This is actually a good thing as it will force us to continuously develop our skills and improve to remain relevant.
I personally feel the next 10 years will see our roles gets more technical but also include agile leadership aspects due to the fact that automation is often very closely tied to an improvement in agility.
We can often be seen as the last piece to a complicated puzzle, this can bring about its own sense of responsibility and pressure. My advice to anyone in this space is to not rest on what you know but to continuously learn and develop your skillset, the above points may be my reflection on the last 10 years, but they will also be used as a springboard to make myself even more useful in the test automation space for the next decade and beyond.
