{{announcement.body}}
{{announcement.title}}

How to Avoid Test Automation at All Cost

DZone 's Guide to

How to Avoid Test Automation at All Cost

Test automation is becoming more popular. How can testers in DevOps avoid having their jobs become automated into oblivion?

· DevOps Zone ·
Free Resource

So, your manager comes to you one day and says, “We are way behind the times," he yawns mid-sentence.  "We might want to think about automating our testing.”

 It’s phrased as a suggestion, but you know it’s a command and he just doesn’t want to seem like a pushy manager.

As a tester who primarily focuses on manual testing, testing strategy, and user acceptance, you obviously want nothing to do with automation. The complex workflows in your organization can't be automated well, and you’ll be saddled with defending it to developers. Plus, as plenty of websites and articles point out, automation is killing jobs!

Your career in software testing is over if a robot is running all your tests. (It’s a rather boring robot, too, if we’re being completely honest.) With a robot running the tests, writing the tests, evaluating the results, thinking critically about quality concerns with new development, and understanding user requirements, what would be left for a living, breathing, coffee-tweaked, human tester?

I’ve seen several teams working through their transition from largely manual to primarily automated testing. Unfortunately, some succeeded.

However, I also saw those teams that failed to automate without being able to implement more than a few unit tests. I’m happy to share four best practices I’ve learned for how to avoid automating your tests at all costs.

1) Discourage Learning About Programming or Technical Tools

First, and this one’s important, do not let anyone research available testing tools, or how to use them. Really, any learning related to programming or technical implementation should be avoided.

The only way for your quality team to suggest or create automated tests is if they know what can be automated. Present learning programming or technical aspect of automation as unnecessary. The developers already know the technical side and can implement it, so of course, the quality team need not know any of it.

At the same time, scuttle knowledge about the available testing tools away from developers. Make sure they know that the testers are solely responsible for test strategy. This way, even if the developers have the technical knowledge of how to automate tests, they’ll have to do it without the experience of the QA team.

To foster test automation, development, testing, and other roles must work together to form a smooth, continuous integration pipeline. If you can prevent cross-learning between roles, you can prevent any one person from creating ideas about what should be automated and how it could be automated, effectively stunting progress.

2) Suggest We Automate Only Things That Are Hard to Automate First

Next, make sure to tout the benefits of having a fully-automated workflow test. Let everyone imagine a world where the lengthy manual UI tests are run automatically with all new development. Remind management of all the expensive regressions that had been missed in the past, that could be covered.

This may seem counter-intuitive at first, but fear not! Fully automated workflow tests are helpful, and if implemented well would surely increase your organization’s confidence in test automation, dooming you to a dreary robot takeover.

They won’t be implemented well, though. Complete workflow tests, especially through the UI, are the flashiest and most exciting form of automation for most developers and testers, but they are also the hardest to do correctly.

Automated tests have inherent flakiness, with larger, more complex tests having more false positives. Complex test scripts typically also take more time to implement than smaller tests for similar benefits. (For some definition of “similar.”) Smaller API or function-level tests are faster, more reliable, and require less environment setup, so they should be avoided when starting out.

If you start by creating large UI tests without the foundation of smaller tests and experience with automation best practices, the tests will have such a high false failure rate that everyone will lose confidence in the tests’ accuracy and conclude that automation isn’t worth the apparently massive effort.

3) Don’t Let Developers Run Tests Themselves

For developers, one major benefit of automating tests is getting instant feedback about whether changes work. If developers can easily run existing tests, it speeds up development and shows programmers the direct benefit of automated testing when bugs are found. Clearly, this practice must be quashed before it begins.

“But how?” you may ask, still concerned about the AI uprising. Well, you can’t prevent a determined developer from using tests. However, you can make it unreasonably difficult for the average person to run tests.

A great way to make testing more difficult is to use different tools than are used in the development itself. For example, if you’re team uses primarily C# or Java, use a JavaScript-based web driver for UI automation.

Make sure your test harness is also difficult to work with in the developer’s IDE. Ideally, it should only be easily runnable from outside an integrated environment with extra setup, like installing new frameworks, required beforehand.

For example, if no one at your organization is asking for business-readable tests, mandate a BDD tool like Cucumber. Then tests must be written in a business-readable form and bound to the readable syntax with code. Cucumber/BDD can provide great benefits. But, if no one asked for those benefits then the extra work implementing the framework will just be extra work.

4) Only Bring Up Automating Features Once the Development Is Done

Finally, as a tester, make sure you stay out of any development decisions. Decline any design meetings, and do not ask to preview any development before the code is out of a local environment.

Often automated tests need the code to be written in a testable way. Sections of tricky logic need to be encapsulated with discrete inputs and output to be easily tested. Having a test ID on HTML elements will save time on maintenance when layout or styling changes.

If developers aren’t writing tests themselves, and the people writing the tests aren’t present when the code is being written, the only way those changes will be included is if they are done after the fact.

As most of you probably know though, internal-only tech debt rarely gets paid back. This ensures that the support needed for good automation will likely never be prioritized.

Closing Thoughts

Clearly, this is meant to be ironic. These are practices to be avoided.

I do sometimes hear concerns about automation removing tester jobs. I wanted to address that concern a little more seriously since it is a reasonable worry.

In the foreseeable future, losing quality assurance jobs to automation is an avoidable situation. Test automation largely augments quality assurance rather than replaces it. Right now, there is no threat of (boring) robots replacing the aspects of testing that require critical thought. James Bach and Michael Bolton have a great article distinguishing the automated part of testing, from the parts that require thought.

In truth, following these steps is more likely to hinder a dedicated tester. Doing as I suggested here facetiously may slow automation down, but automation will eventually arrive regardless. Rather than fight the inevitable march of technology, embrace it to be better prepared for when it’s here.

Topics:
devops adoption ,quality assurance ,automated testing ,ui testing ,test automation ,adoption challenges ,qa and software testing ,testing tools ,manual testing

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}