How to deal with automation naysayers?

Question

In my team, there are a number of experienced QA people. I work mostly on developing tools to make the QA process easier for these guys, such as developing test automation.

The uptake has been slow, maybe due to the fact that these guys are stuck in their ways, and don't really understand how test automation can help, and make their jobs easier.

I've tried presentations/demo's etc. to get my point across, all to no avail. I've even spent time automating almost the entire QA process for a simple application, only for the QA lead to use outsourced QA testers to test it!!

There's buy-in from management, but no mandate to say that automation has to be used.

Has anyone ever faced a similar situation? Don't get me wrong, these guys do a very good job, but I'm beginning to think that I'm wasting my time in this company (a large multi-national), and that my time would be best spent looking for another job.

Answer 1

I definitely feel your pain. As noted in a question I had (I'll link in a minute) I too work for a 10-digit revenue company, and our primary software has 0 automated tests for over a million lines of production code.

It boils down to the same philosophy that a lot of developers have about using external libraries rather than rolling their own: we fear what we did not create. We simply don't trust tests we didn't write, libraries we didn't write, and tools we didn't create ourselves.

I once had a boss (who was a bit of a self-pompous you-know-what, but was undoubtedly an intelligent man) who said "Software is developed by heroes, and maintained by mere mortals. If you want to develop new software, it requires a heroic effort on the part of a developer." I don't necessarily take it to the extreme he did, where he thought you had to burn yourself out at 80 hours a week for a month to get new software done. But I do believe we need to do something heroic, bold, and noble to get things done in a corporate environment.

So the best thing you can do is make some automated tests. Just keep making them. Encourage development to also make some simple automated tests for some new code they write, and new bugs they find. It will take a few months of patience, but eventually one of those tests is going to catch a bug. Then, when they see the effectiveness of this test harness, they will start to realize that it's not so evil after all. Soon another bug is caught. And another. And another. Then, at the quarterly/annual review, you can say "we were able to stop X amount of bugs thanks to the automated testing, saving us an estimated T hours of testing/development time. Imagine how much we could save if we had more test coverage?"

You need patience. If you don't have automated tests, it's likely the application doesn't lend itself well to automation. This means you will have an uphill battle even getting the tests created. But it's worth the fight.

About looking for another job: this should always be on the table. If you're not contractually bound, I don't see why a smart developer wouldn't have his resume updated every 2-3 months, just in case. One shift in management can turn a dream development shop into a dismal sweat shop. If you go over a year with zero traction gained, I would encourage looking for employment elsewhere.

Edit: I neglected to mention something very important. If you're able to reduce the tension between the your group and whatever group is blocking you, things will run better on both sides. I'm not saying you have to devote your life to buttering them up, but for example at my work, some guys from application support and from development go and play frisbee on Wednesdays in the summer time. It's just an hour or two, but when you see them at work the next day, even if you have to give some difficult news, it makes it easier.

testerab's answer to this question has some great things to say about building credibility and relationships between teams.

Answer 2

I think you'll need to understand why they are being nay-sayers. It may be that you've landed in the snake pit of office politics and you're wondering why because herpetology isn't written in your job description.

Some of the complaints you may have heard from the Knights Who Say NIH (Not Invented Here)! may include:

Why Change? We've always done it the old way...

Sure, the old way works, but we've seen what happens to companies that don't change - they become extinct.

*Why Now?"

We have to start sometime. I've been given the go-ahead by management.

It won't solve everything

Nothing solves everything. Automated testing will help make it easier to ensure consistency in testing as well as ensuring that previously found bugs don't return in future releases.

You're wrong and here is why...

To some people, every discussion is a verbal match that requires someone to win, and the opponent defeated. A demonstration that can show that automated testing solves some problems that are hard (or "dirty" or just plain unpleasant) would help solve these folks. The part where you said "I've even spent time automating almost the entire QA process for a simple application, only for the QA lead to use outsourced QA testers to test it!!" gives me the feeling that they knew and didn't want to be proved wrong. Some people take being shown to be wrong as a moral judgement of themselves; you showed them that they were incorrect in this instance, therefore they are wrong in all other instances. About the only way to deal with these folks wold be to spend some time reading the series of books by Suzette Haden Elgin that have "gentle art of verbal self-defence" somewhere in the title.

Talk is cheap! I'm from Missouri, Show me!

These folks could be swayed by a demonstration (see preceeding paragraph), while the folks who engage in conversational warfare cannot be swayed by demonstrations.

It is too much work

Automation takes time to set up. Once the scripts are created and set up, it can be done easily. One anecdote I used in an interview today was mentioning continuous integration servers and how my last employer would have greatly benefitted from having one (I set one up at this job and the folks love it, although they didn't understand it until I set up a demo of one on my development machine). The guy who made the install packages was an earlybird - his 8hr day ended around 3:30PM. The developers were evening people, so they'd be working to 10PM, but if there was a build, they could not hand over the install to the QA people until he came in the next day at 0600. Running some automated tests over the code would enable the devs to take care of a number of known bugs/issues (not all devs would bother running the unit tests before checking code in to source control), and that would take care of a number of tests that the QA staff would have to do every time a new build was ready to be checked. Not all the devs had the same stuff installed, and some would forget to switch to a release build, so the consistency was sad enough that only a couple devs could be trusted to make builds (one product was so flaky that the only machine that could reliably build it was one left behind by a dev that quit around 2004, so his machine had to be carefully maintained until the product was rewritten so that there was something to ship and sell to customers). A build machine (aka CI server) would have resolved so many of these issues that they would have been forgotten in the mists of time.

We already tried this...

Yes, well, times and techniques have changed. That was then, and now we can do X, Y and Z.

Cut down this forest with a herring!

Getting back to the beginning, learning office politics is a crucial skill. Along with maintaining your sense of humor. Learning office politics is a nasty task, but it has to be mastered or else you may as well have WELCOME tattoed on your forehead.

experts define office politics as "the way in which workers recognize, and seek to reconcile, their competing interests."

We like to pretend that we operate in a meritocracy, where what you do is more important than who you know, and where we're all in this together to make the company a better place. The world isn't fair. So learn office politics, not so that you can play them and abuse others; but so that you can bend like a reed and use your opponents' misdirected energies against them.

Answer 3

Reading between the lines of remarks like "these guys are stuck in their ways", and "I've tried presentations/demo's etc. to get my point accross, all to no avail", "a lot of them don't understand how [it] works" - you're coming across here as if you've mostly been focused on telling them how great automation will be, rather than starting out by demonstrating that you're really interested in listening to them, understanding their work, and hearing about their problems.

Is that a fair assessment?

If so, then you have a credibility problem to solve. It doesn't matter how great your automation is, if it's not solving the right problem. And if you're inadvertently giving off the impression - even if you never explicitly say this - that you're right, and they're just ignorant and hidebound - then wow, you will need to be quite humble for people to listen to you now. Also - have you actually seriously considered that they might be right? That your approach might well be missing something?

MichaelF's advice is good: get to know people, spend time with them, understand where they're coming from - but you replied by saying "maybe time for another demo!". NO! Stop with the demos already! You did that already! More than once! It didn't work!

Forget about going through management. You know they're disconnected from what's going on. Take Michael's advice and sit down with the guys at lunch. Sit with them while they're testing, pay attention to what they complain about most, what frustrates them - don't assume that something you'd find boring is the same as what they'd find boring. Stop trying to automate "the entire QA process", as if that was even possible (if you can automate thinking, analysis, exploration, learning, and design, then you should be making your millions out of your AI instead). Start by planning to just learn about the problems people have and just stop yourself from trying to propose solutions too early.

Try to find very tiny problems that aren't actually tests - maybe there's some tedious data setup to do, and you think you can write something very simple to help with that - but don't rush off and do it - ask a bit more first, to make sure you understand the problem, and just as important - to show them that you're making an effort to understand the problem first - and ask them if this would be something that would help, and would they mind very much having a little look if you just spend half an hour knocking up a quick little tool? Make it small, and low-key, and something that solves an immediate problem.

Answer 4

Seems like there is a disconnect between management and the QA Team, although I can't tell what Management is buying in if the QA Lead is outsourcing when you have done work. Communication could help, but having it come from the top down should be done diplomatically.

Try to find out from the QA Team what their issue is, do they fear automation will put them out of a job? Something else? Understanding their stance will be a better help to you than agonizing over the issue and wondering why they don't listen. You have to convince them what you are doing is to help, sell that to them and they will join with you, rather than be against you. Remember these are people on your team, or you need to work with, they are also customers if you are building for them. Sit down with them at lunch, get to know them, then try to find out where they are coming from.

Only you know if its worth looking for another job, typically if my first reaction when walking in the door is negativity about my day then its time to leave. If I can come in and still think I am doing something cool and fun, then I will stay and try to resolve the issues.

Answer 5

There needs to be a tangible benefit to the automation for people to take advantage of it. People rarely resist making things easier for no reason. How easy are the tests to run? Are the results easy to interpret? These are issues that may seem small to you. To tester who has never encountered automation before, this learning curve may be steep. As a result it may seem easier to the QA lead to simply outsource.

Prove that automation works. Run your tests in parallel to the manual testing effort. It is hard to argue against test automation when you can show it is finding some of the same bugs a manual test iteration is uncovering. Initially you might have to do this off your own back. eventually you will probably find that the testers start to rely on your scripts to catch the low hanging bugs, leaving them to focus on the more complex testing.

Answer 6

In my opinion, the only way to "convince" naysayers of the benefit is to show them real time in real life. Do it. Do one test all the way through. Test it in a bunch of environments and scenarios to demonstrate that it works.

Software has moved to agile. For most of us, happily. CI/CD is a significant goal. That latter does not work without test automation. Dev loves unit tests. API tests. The MAIN obstacle to these is simply time. Dev can wrap their heads easily around headless testing.

UI test automation has a history all its own. And the number one obstacle to successful UI test automation is this history. MANY of us have seen automation attempts of this kind fail over, and over and over. But somehow we miss the lessons that these failures teach.

Try this.

https://www.stephaniestowe.net/success

See if this info applies.

Answer 7

If the nice-guy approach does not work, try this:

Automate the application on the sly if possible (some if not all) without their notice.

Ask them to do a daily regression of the application (a complete run over) and insist on having the results fast. When the test suite grows in complexity and they start getting brain dead by doing the same tests repeatedly, then run your test scripts and show them how it's done.

That should get you started.

Answer 8

Maybe this—Dale Emery on motivation—will be helpful

http://cwd.dhemery.com/2005/05/motivation/

---Michael B.