Discover the top automated testing strategies and tools. This week, Eliga’s Application Engineer Ferenc Kovacs discusses why most developers don’t want to write automated tests.
Who should write automated tests?
It’s a simple enough question. However, if you asked five different people, you will most likely get five different opinions on the topic. With so many views out there, I wanted to share my thoughts on the subject.
Developers write tests faster and manage the codebase better than a test automation engineer would. Why use a dedicated test automation engineer when developers are better suited to take responsibility for writing and maintaining the automated test suite? Most test automation engineers do not think of themselves as software developers or ‘coders.’ So, why do we ask them to code automation tests?
‘Surely, coders should code, and testers should test.’
-Ferenc Kovacs (Eliga Services)
It is becoming more and more accepted for developers to maintain the automated testing suite. In fact, the DORA State of DevOps research program found that when developers are primarily responsible for creating and maintaining suites of automated tests, it’s easier for them to fix acceptance test failures, driving improved performance. Despite this, many developers are reluctant, if not resistant to write automated tests.
Why developers don’t like automated testing
I don’t need to tell you why testing is important or explain why automation testing is a good idea. We all know that an effective automated test suite speeds up future development, making it much easier to identify if your code is production-ready. Then why is it so hard to get developers to write automated tests? This is a question that we’ve asked ourselves a lot, working at Eliga.
We’ve identified three challenges:
1. Automation tool(s) are unfamiliar to developers
Most developers have never really paid much attention to automated testing applications, never mind practical experience implementing automation testing – not to mention when ‘non-coders’ managed the suite prior. This, together with flaky tests and a poorly maintained codebase, makes the uptake all the more daunting and uncomfortable. In turn, many developers will do the bare minimum or even worse, not write any automation tests at all.
2. Time constraints
This challenge comes as no surprise in software development. We always need things yesterday. The last thing on our mind is taking on more than we need to, especially tasks that will only pay off in the medium to long term. Furthermore, just getting started and getting our head around the automation suite is the most time-consuming element of test automation.
3. Developer resistance
Let’s be honest. Developers don’t love automation testing or testing in general. Luckily, unit testing is becoming more and more the norm in software development; so getting push back, in this regard, occurs less and less. But automation testing still has a long way to go, before it is as warmly embraced as unit testing (tongue-in-cheek moment). The benefits of automated tests are not always accepted by all developers, and this is even more prevalent when the business has an ‘automate everything’ approach.
How we alleviate these automated testing challenges
Let me start by saying that nothing is perfect. You will always have some level of difficulty that comes up in a project, but we have found some effective ways to smooth the bumpy road of test automation for my much-loved software development peers (no one is forcing me to say this, promise ;-)).
Some key elements to consider are:
Testing strategy
A well-formed testing strategy goes a long way in ensuring a good developer experience with testing automation. A good quality assurance engineer will immediately be able to identify what should or should not be tested to avoid falling into the trap of automating for the sake of automation. For example, tests that are not repeatable are not eligible for automation testing.
It goes without saying that the quality assurance engineer writes the stories for test automation. Additionally, some good rules of thumb include not writing automation tests for content and configuration. All too often, we see automated tests that test the configuration of the application to make up for a lack of validation.
Testing tool
Use the right tool for the job; there is nothing worse than trying to shoehorn an application into doing something it’s not built for. Another pitfall is selecting an automated testing suite that doesn’t support the browsers you need.
Take your time and do your research You’ll be thanking yourself later. It’s also a good way to buy in on your testing automation approach and allows your software developers to build familiarity with the testing automation suite.
Here is a quick bonus cheat sheet to help you along your way:
Testing time
Make sure to schedule time at every sprint to allow for automation testing. Repetition and discipline are key to obtaining the benefits of automation testing. Student syndrome is a real thing. Don’t leave it to the last minute right at the end of your project.
To summarise
An effective automated testing suite can be an asset if used to its full potential. All you need is a clearly defined testing strategy with a quality assurance engineer to back it up:
- Having a driving force behind test automation makes a world of difference in terms of approach.
- Selecting the correct tool for the job will make things easier from the start; it only takes a single spike to research.
- Take time to ensure you get the automation tests written. Work with your project manager to ensure you have enough time to work these into each sprint.
Finally, remember this is not a set and forget approach. You will need to re-evaluate and refine your approach throughout the evolution of your application, but, most importantly, have fun with it.
Happy coding! Now, you’re ready to build amazingly robust solutions.
If this has raised a few questions or you would like to explore automated testing, then please do get in touch. Eliga Services has the knowledge, team and experience to support you.