When someone says they want to learn #Automation, I have to ask WHY. WHY do you want to learn automation?

🗄️ Archive
1

This is the text I made for a post on LinkedIn, and one of the comments was from Rosie suggesting it would make a good post over at the club, so here it is:

When someone says they want to learn #Automation, I have to ask WHY.

WHY do you want to learn automation?

“That’s where the jobs are.”
Maybe, but aren’t there also jobs for programmers, plumbers, retail workers? If this is such a switch for you, why not do a completely different job?

“Manual testing is dead.”
It most certainly isn’t. Automation can make repetitive tasks quick, but it isn’t cerebral. It isn’t able to speak with someone to understand what’s going on. It isn’t able to think about what tests should be done.

“It’s the only way to progress.”
Then are you wanting to progress into something you aren’t wanting to do? See the first statement for thinking of it as a career change. Also, what about a lead/manager position? Coach? Trainer? Do you have to keep progressing, or can you be happy doing what you’re doing?

“I enjoy testing, but I also enjoy coding and want to combine them.”
This is a GOOD reason! You know what you enjoy doing, and want to expand upon it. Not from an external pressure, but internal desire.

If you do things for the wrong reason, will you be happy?

So next time you think you need to learn to do automation, ask yourself WHY…

For anyone interested in reading the comments, here is a link to the original post Lee Marshall on LinkedIn: #Automation | 69 comments

10 Likes
2

Hey Lee. I am going to give my 2 cents as to some possible reasons why people seem to just like to say “I want to learn automation.” I am an automation engineer and have been for the past 5 years. I came from a dev background and realized I had a knack for knowing how to test software. So it seemed like a natural fit.

1.) People feel less intimidated becoming an automation engineer vs a typical software engineer. I think that the concensus is that automation is technical but not THAT technical so if you want to do some coding but don’t necessarily want to learn the ins and outs of JS or functional programming, automation is a good way to go.

2.) More and more organizations want to “automate everything”. So…if the organization had manual testers and they want to automate everything, this seems like the only way to maintain a role. I understand what you were saying with “That’s where the jobs are” but a lot of people don’t have the luxury to just pursue a role because it’s their passion.

3.) Automation is often seen as QA 2.0. I have been on both the dev and testing side of the SDLC and I can say from experience that people seem to listen more when you are an automation engineer. I think the fact that you write automation code tells people you are more technical and it creates the perception that you are a more technical engineer. It seems like a step up the ladder. Again, perception.

4.) In a world of increasingly complex software, it stands to reason that our skills in tech do progress. I don’t think that every single QA Engineer needs to learn how to write code but it doesn’t hurt and is a skill set that sells on a resume.

Can you give me a list of what you would call the “wrong reason” to learn a skill?

3 Likes
3

Beyond the examples I gave in my original post?

Big one for me is “Because I’ve been told to by my manager.”
Yes, jobs eventually become obsolete. You don’t have people acting as telephone operators plugging lines into different ports, or coal shovelers on trains (generally, the rare few exist). But if your job is being made obsolete and they say learning X skill will let you have what the job will become, is that the job you want to do? Maybe it lets you have a fresh start on something else, rather than whatever the new version of your job has become.

Now, within testing, if someone says you can only test if you know Ruby, SQL, Java, etc., that to me shows they have a limited understanding of what testing does. If you understand the code will that let you perform glass box (I hate the term white box) testing by seeing what it does. But it can also narrow down the ideas of tests you might want to do, which would happen if you had to do black box due to having no understanding of the inner workings.

Peer pressure is another, which ties back to the idea that “That’s where the jobs are.”, as doing something because everyone else is, shouldn’t be why you do something unless it is because you want to. If you see everyone you work with learning a new skill and it intrigues you, that’s fine. You are likely just a late adopter, and need others to try something out first so that you know it is worth doing, as well as having a larger support network to help you if you struggle with the new skill.

Also,

Then they will struggle, as it is impossible to automate everything, and the more companies keep wanting to do that, the more they will fail.
You can’t automate a new process. Someone has to manually do it first.
You can’t automate going off the rails, as automation is the rails. What if you notice a button is in the wrong place? If the automated script looks for it to simply exist, it will miss it. But what if it was meant to move? Then the script will fail, need amending and re-run. As if it is ignored for failing due to being a known issue, then the script is worthless.
You can’t automate reviewing the requirements, or having conversations with people.

Automation is not the answer to all things testing, and I will continue to stand against those who think it is.
It has a place, but along side “manual” testing, which is to say, it is all simply testing.

3 Likes
4

Not sure how formatting and “quoting” people’s posts in thread works on here, but I’ll bring out the points and add anyway.
Lee wrote "Because I’ve been told to by my manager"
This was the message I got about 3 years ago, I had already been an automation tester for some time, but most of the test team (non-agile world) were manually testing and wanted to comply. So I helped train people up in scripting and programming, but sadly a re-org about a year later was too soon for many of them to cross-skill. Moral of the story, it can often save your job, but there are other reasons to go “automate”. I agree with James Bach, whom I disagree with often, on using programming tools to make your testing job easier and to test in smarter ways. Basically because the thing you are testing is software. Having software skills will help you not only understand the process of software creation and thus make you better at understanding how to talk to and listen to the developers on your team (you are in a agile team now are you not?) But will mean you will now know about how software gets built and get involved in design and architecture discussions which are critical parts of the testers job.

So I see automation as the testers way of learning how to understand the SDLC and the difficulties “in the factory” that make software hard to produce. The testers job is to make it easy to produce widgets, and to do so more quickly, since that’s what sells.

You can only test if you know Ruby/SQL/Java… Is not a helpful discussion starter, I’m junk at Java, and my Python is middling, but because I have history as a C++ developer I find I script in Python, and never Java. I can read most languages, but find that the test automation engineer spends much less time coding and much more time debugging the test scripts and their product interactions, than actually becoming a guru on a small set of languages. You become a generalist more often than a language specialist, because automation is most often about integrations at scripting level. And I find the black-box mentality to testing much more useful in automation than white-box (glass :slight_smile: ) . This is my experience, others may differ in mileage, but I choose to go for value from end-to-end and full system checks than for smaller integ tests at a lower by personal choice.

Pressure
The pressure most often to automate is not peer, but from management who want teams to become more agile and fast. The last 2 jobs I have experience of places with not that much test automation in place in areas that count. Management want faster releases. Hold the course.

1 Like
5

Because my manager said I have to - From what I’ve seen this is absolutely the worst reason to learn automation. Managers who say this are misinformed at best, and can destroy a good team. The best outcome of a managerial “thou shalt learn automation” is an unhappy tester. The worst is a good manual/exploratory tester who actively resents being forced to learn something they have no interest in and stops caring about the work they’re doing.

I’ve seen this happen, usually with management who want an instant fix to problems that are typically cultural when you go back to the underlying causes of problems. The company’s software is chronically buggy and unstable? Couldn’t possibly have anything to do with the way management halved the time the team had to work on the latest feature because they’d over-promised to get the contract. Or the way management routinely overrides the concerns of the test team and releases with serious bugs. Or… well, you get the picture. The sales pitches of various automation tools do not help.

Me, I learned because I like programming and I like testing, and I’m a lazy tester. I want to be able to do it once, right. Automation helps with that goal.

2 Likes
6

If you highlight text, it gives you the option to quote. I only found by accident.

1 Like
7

Bear in mind my response was to the question asking me what are the wrong reasons to learn a skill, which I took to be more than just automation.

What happened with the people you trained up in that year before the re-org changed things? Were you no longer able to train them after the re-org, or were they in roles/teams where they wouldn’t be able to apply it?

Weirdly, I’m used to working with language specialists, as we have .Net developers, Oracle developers, ETL developers, and so on. Even for automation, it is all based on Selenium, so our automation testers are being trained on how to create and maintain Selenium scripts, rather than automation as a broad concept.

8

I completely agree, as I’ve been in the situation where they tried to put several of us through automation training. I tried it, and knew it wasn’t for me, and started to put me off testing. Thankfully, I began to focus on what I do and don’t enjoy doing, and said automation isn’t for me, and advised them to spend that time and effort on someone who does want to know it.

Your reasoning for learning automation is a good reason. If people know why they want to learn it, and accept that is why they want to learn it (not have to learn it), then go for learning automation :slightly_smiling_face:

1 Like
9

Cool, thanks Lee, here we go…

Every manual tester will benefit from more knowledge of the SDLC, and the architecture internals. But some of them are just good at thinking like a customer thinks, and are good at getting into role based testing. And knowing about architecture quickly makes that kind of testing harder to do when you need to even do OOB testing, it’s much better to have a white-box in front of you. My concern is that I am talking about agile teams in general are the main today, and agile teams will not have a manual tester incumbent.

I like the idea of being a lazy tester, much like Napoleon apparently used to love lazy generals. I kind of see automation as a way to have someone in the office running tests all night long while you sleep, for free. Well, no automation is for free. And would you have a 8 year old kid do all your testing for you? Because that’s what you are going to get out of any automation done without rails. I normally ask them to go read “The Mythical man month” book.

10

Your statement is not, sadly, as accurate as I wish it was. My circumstances come to mind: I’ve been trying for years to get half-decent automated regression into play where I work. I can’t because I’m in an environment where I’m the only tester, the software can’t be unit tested (Classic ASP, million-plus LOC that we don’t have the time or people to replace), and getting the thing tested takes priority over any kind of automation.

A good tester with excellent ability to explore and find bugs is perfectly workable in agile teams. They may not be able to step in with coding, but they can certainly help with product owner and scrum master work, as well as guide any developer-produced automation.

11

@ThePirateTester I hear you. I know an extremely good manual tester who was ready to walk over a managerial mandate to learn to automate. Fortunately they backed down and realized they needed both manual and automation specialists.

2 Likes
12

I think you have the tough job as a tester. Working for a company who is not taking quality seriously are probably not charging the top dollar for their software that they could be doing. I have always been a coder, and I moved into testing a long while back, so software creation process and architecture is important to me.

I think as a tester, you do need to either understand the whole development process, or have a product owner or release team that do. PO and release people often are not coders, but if they are, then they can help the professional manual testers. Software quality is a lot like working in a hammer factory, where the wood for the hammer handles comes from is crucial to the hammer quality. Reality is the guy on the assembly line and the guy who boxes them up, do not care if the hammer handles were made of Ochrama wood or Hickory. If the process is not designed to allow it to be verified later, garbage will get into the system in the long term.

13

I’m a very lazy tester and how I pitch it (to teams / employers etc.) is I don’t want to have to constantly keep coming back to the same ticket, So I’ll find all the bugs I can so that it will be working correctly by the next time I have to test it!
Plus I like automation, though have found it a struggle being self taught and the only QA in my company that runs the suite.

2 Likes