What does the future hold for a manual tester moving towards automation?

(To Be Archived) Questions
1

Hi there, I appreciate this is a subject which has probably been asked before but it is something that has been concerning me for a while so thought I’d ask!

I’ve been a tester now for a number of years; when I first started out testing it was purely manual and there was no offering from the company I was working at to learn automation. I’d say, over the last 18 months, my interest in automation has increased predominantly because I have an interest in it and what to learn programming, but also because I see the benefits it brings to testing and the time that can be saved(specifically referring to regression testing, in my case!)

I’m way down the road towards learning programming and automation and have confidence in being able to write smallish frameworks using the Page Object Model, however I’m by no means an expert and it will be a little while longer before I am proficient. Like a lot of people the main barrier to progress is time; I’m spending 2hrs a day(in my own time) learning automation; whilst this is a decent amount of time it’s maybe not significant enough to progress at the pace I’d like.

With the above background in mind, I’ve noticed a few postings on forums where automation specialists are rightly concerned about people diving into automation, possibly adding those skills to their CV when they have only been learning it for a few weeks. There have been comments that in order to master automation this only comes with things like a computer science degree which in itself is years worth of studying. I’m thinking(hoping!) that there must be a few testers who are in the same position as me. My concern is what does the future hold for us as testers?(those outlined above moving into automation) Almost every role I see for testing now requires some kind of automation experience. If we’re not yet at the desired standard does this make us redundant?

Appreciate this is a long winded post but would be really interesting to hear peoples thoughts

1 Like
2

Hi,

That IS a long post and poses many questions and points.

Picking on some of the more general points first…

  • automation specialists are rightly concerned about people diving into automation, possibly adding those skills to their CV when they have only been learning it for a few weeks

I guess that’s applicable to any C.V. for any skill for any industry and not just automation experience. Those who claim to have more experience are usually found out during interviews.

  • in order to master automation this only comes with things like a computer science degree which in itself is years worth of studying

Hmm, I have a computer science degree but I still think people can learn and master new skills without the formal qualification. What about the success stories your read from such sites as Free Code Camp, a lot those guys are like you, no formal degree but with time and effort, they achieve. I create automated tests, but I didn’t cover it in my degree, not such thing back then. Does that mean I cannot ‘master’ either? Re ‘master automation’, I wonder what that actually means? Is there a set of skills that makes someone a ‘master’? Skills and experience makes you better at testing, same as anything else. IMHO, these naysayers are fearful that others are using open source to ‘muscle in’.

Moving towards automation, you mention page objects, so I’m assuming you are learning something like Selenium to drive browsers. Automation is, IMHO, wider than that. There are browsers tests, but you can also automate API Testing (Google ‘Chrome Postman’ for a free API test tool). There is Performance and Load testing that can be automated too, see JMeter. There have been a few posts on here that talk about ‘what is automation’, ‘what does automation mean to you’, have a read of those.

In terms of what you doing today, I’d say keep going and ignore negative comments. If you’ve managed to create a simple framework and understand page objects, then you’re gaining experience and skills in the automation arena. Do also look at other areas of automation.

Your post says that in the past, there was no offering to learn automation at work. So, I’m sure of your current situation. All I can suggest is look for opportunities at work to help build your skills. E.g. is there an API you can access? If so, try Postman and create a small test suite to test the API. Similarly, you could look and performance and load, but not against a Production site/app! :wink: Is there a (web) app, you have access to at see work? See if you can use those to automate. Maybe if you can build something simple that demonstrates some value, then you might get the support you need, you may lose a few lunchtimes, but it could be worth it. My own learning style is that I don’t benefit from wooly examples, e.g. foo and bar to learn stuff. I find I learn best with a real world problem in front of me. Find something ‘real’ to have a go at testing.

I think you’re doing the right thing, you’re learning new skills. Keep doing that and ignore the negative stuff.

3 Likes
3

Hi Andrew,

It sound like you’re possibly a little bit further in your learning than James who posted this Manual tester looking to move into automation - help required! but maybe some of the responses on there will provide some insight for you.

Firstly I would say that most of the best developers I know have no degrees in software engineering/computer science so I’d not worry about that part at all!

If you’re not yet at the desired standard you’re showing huge promise I would say and the fact you are pouring your own time into this will speak volumes to potential employers. The right employer may even hire you as you are right now because you have a solid testing background and a proven willingness to learn. If you’re looking to get a job where you might learn on the job, explaining things like What does the term Automation mean to you? and as @chris.adams says, knowing that automation is wider than UI level and being able to discuss that.

I’d suggest you also look at #testchat from last night too, there are some interesting points raised there about automation in general.

Lastly, there is a post on here Products and sites to practice testing on which should give you a few more areas to use for practice if you can’t get the opportunity to in work. I used a lot of them myself to get a good grounding before I let myself loose on a work product for automation.

2 Likes
4

What’s the job market for automation?

Pretty good. Seems to be in growing demand. I think it’s worth knowing.

Should I move towards automation?

From a career perspective having some automation tool knowledge and how to write and maintain quality automation tool code in a suitable environment with knowledge of the relevant IDEs and version control systems is a good idea.

From a moral and testing perspective the question makes much less sense. Putting careers aside for one second; in the reality testing isn’t about automation and automation isn’t about testing. Testing is about learning information to close the risk gap and communicating that information to the people who matter. Whether that’s done with a tool or not isn’t important - what’s important is using the right tools at the right time and having a good understanding of the cost of those tools. When I use a tool to replace what I’d do without the tool I may gain benefits like the time I save or insights I gain or increased testibility or ability to repeat coded checks quickly. I may lose benefits such as leveraging the exploratory nature of testing quickly, the time and effort it takes to learn the tool and get it set up in my environments, everything the tool doesn’t notice that I would have noticed if I weren’t using it, the abstraction failures I make when I assume the tool does what the code “says” it does when I should remember that computers don’t understand English, the maintenance cost of using the tool and of course the way that I work changing to suit the way the tool wants me to work instead of me holding the power over how I achieve what I want.

Sometimes when a company takes on a tool they want to be sold a solution to all of their problems. Tough break, because testing happens purely in the mind of humans and nowhere else, so the tools we use should be powerful and flexible and fulfil our need for multiple oracles and be in the service of our test strategy. A tool isn’t a strategy, but a strategy probably uses a bunch of tools.

You don’t need a computer science degree. I don’t think I’ve used mine a day in my life, except the philosophy module I took which I use every day. When I hire I nearly ignore degrees. I don’t think academic institutions have caught up with the reality of testing yet, although I could be out of the loop. If you want one, go for it, but it’s not cheap (at least here), and I don’t think it’s worth the cost.

I’d be wary of listening to the advice of anyone who considers themselves an “automation specialist” - make sure they’re a testing specialist too before you take too much of their advice on board. Imagine taking advice on a career in painting from a “paintbrush specialist”, and you’ll see what I mean - Monet and Pissarro were paintbrush specialists but they were also amazing artists. Writing code is the easy bit. The hard bit is writing the right code for the right thing for the right reason and making it easy to understand what it’s doing (and hard to misunderstand what it’s really, actually, doing) as well as balancing that with what the tool can’t do and what you therefore need to concentrate on elsewhere. Coded checks are very useful, but they have important limitations. Don’t feel that automation is some sort of martial art only perfected by some gurus on mountains who hold the mystical knowledge of how to build a Selenium grid. Automation is just a bunch of tools. It’s a bit like saying that you can’t be a musician because you haven’t learned everything about pianos. You need a bit of knowledge about a piano but mostly you need the knowledge and skill to press the right keys in the right order at the right time in the right way for the right reasons.

5 Likes
5

Quick follow up, check out “A Blazingly Simple Guide to Thriving as a Software Tester” by Rob Lambert: https://www.linkedin.com/pulse/blazingly-simple-guide-thriving-software-tester-rob-lambert

Check out the section titled “Automation is the future and testers will be out of a job”.

2 Likes
6

Good article, thank you.

1 Like
7

Test automation is development. And especially if we’re talking ‘behind the UI’ test automation like Selenium Webdriver, which I assume is meant when people refer to “test automation.” Development is a different skill set than testing. I looked forward to doing test automation, as it was a break from testing. Sometimes I would find new bugs during the development of my automated test scripts, but I was using a UI-based test automation tool. Not sure how many bugs would be found when developing ‘behind the UI’ test automation (unless that was the first time they were ever tested).

The biggest benefit for testers learning to code is that you will be able to leave the testing profession and go into development, where there are far more job opportunities, higher pay and a lot more respect.

Remember that automated tests cannot cover all types of tests, like timing issues. Many tests are not economically feasible to automate, so automated testing will always be a subset of tests that could be performed. It would be interesting to see how complex some of these automated tests are - do they cover simple, happy path scenarios or more complex interactions?

Also, who is testing the UI? Not just the usability aspect, but ensuring that nothing weird happens to it or that odd artifacts don’t appear on the screen. With buttons and fields enabling and disabling (or becoming visible or invisible) using the logic in the UI, how is this being tested if a person isn’t involved?

It is my hope that the software development industry will come to the point where they realize both professional software testers and test automators are needed. The professional software tester would be performing exploratory testing, going deeper into the app.

2 Likes
8

If you can learn test automation, code up an example and show people at your work, this may cause them to change their mind and embrace test automation.

Doing this using Selenium Webdriver is more difficult (steeper learning curve) than one of the ‘record and playback’ tools (which you can get a free “eval” copy for a limited time period).

It’s usually tough for testers to invest so much time, because we are usually in “crunch mode” and often victims of ‘schedule compression’ - where development delivers the code late and testing must hustle to meet the original (unchanged) deadline.

2 Likes
9

Hi Andrew,
just keep learning everyday!.
Now you can program basic automation tests…this is very very nice! Remember that a testing automation framework needs a very basic code structure without any of the “complications” a developer should know and use (per example Scala Monads and the likes).

And one thought…“testing automation” in the future is going to be made by developers, not testers.
The “manual” testers are going to be needed always and will not disappear. If your company thinks (as many companies nowdays do) that we have to automate 100% of the tests…we have two options: show them this is a wrong path or look out for another company that knows what testing really is all about (I don´t like to use terms like QA, QA Engineer and the likes).
The testing won´t be never be automated for the same reasons that developing can´t be done by a computer…both are cognitives tasks that requires a thinking human behind. And this is what I really like of testing, you need to use a rational thinking to make your job.

Remember: NO to test automation, it´s just a tool to help testing. Test automation is just a way of “creating” more time to do “manual” testing (or exploratory testing if you like),

Just keep learning everyday…automation or whatever…this is the way to go!

2 Likes
10

Some really interesting views on here, thankyou!

1 Like
11

John - I agree that writing automated tests is a development activity, and the ability and skills learned in doing so reap a number of benefits - time saving in running repetitive tests, achieving better regression testing coverage than could be achieved manually, an ability to work closely with developers and appreciate their craft, and transferable skills should a tester wish to move to a pure development role.

I do want to pick up on a couple of points you raised:
“I looked forward to doing test automation, as it was a break from testing” - automation is not a totally separate activity. You are automating tests, so its related. Did you mean that it was a break from manual execution?

“The biggest benefit for testers learning to code is that you will be able to leave the testing profession and go into development, where there are far more job opportunities, higher pay and a lot more respect.” I disagree with the part in bold. I believe that over a period of many years, as an industry we have evolved to a point where testers are valued members of teams. Our pay rates are in alignment between developer and tester for that reason. If you work somewhere where testers are not as respected as developers, then you are in the wrong place. It’s a minority view, thankfully, and we as testing professionals need to move away from statements like this as it can reinforce the view that testers are less important.

Steve

12

To see if there are more job opportunities as a developer vs a tester, query your favorite job board. You can’t just search for “test” or “tester,” since many programmer jobs contain those words. Best to search on job title containing the word “test” or “tester,” but in the U.S., “QA” is commonly used to mean test.

You could also look at govt statistics on jobs, but they may not differentiate between a developer and tester. A simpler method would be to use your own experience. If the software teams you’ve worked had more testers than developers, then more test opportunities exist vis-a-vis devs. If the ratio of devs to testers was 1:1, then there just as many jobs for testers as there are for devs. In my personal experience, I’ve supported between 4-6 developers and in the U.S., that is common.

Higher pay? Testing and QA pay is all over the place in the U.S.; not sure about devs. Generally, it is much lower than developers. I saw a posting on Dice.com for a tester to test the conversion of data and configuration of a payroll package for $10/hour. That’s not good. Testing and QA jobs are the first to be eliminated in difficult economic times. With development, you can see a product. Not so with testing.

Respect. If you’re working in a place where QA and testers get a lot of respect, please let me know where you work, so I can apply for a job. As a QA Lead for a multinational project, I had to write test plans but had no authority to enforce them. I’ve also had the case where the Dev Manager went ahead and deployed code to prod, even though tested hadn’t finished. Sadly, in many companies, QA is just a checklist item. It’s there so they can point to it and show clients “We have a QA Dept.”

"I looked forward to doing test automation, as it was a break from testing.” Yes, that was a break from manually testing. I have found bugs while writing test automation scripts, but this was using a record and playback tool. Had I been using a framework that tests functions “behind the UI” these bugs would not have been caught because it was a UI bug that caused the error. In a case earlier this year, pressing the ENTER key, instead of mouse clicking, revealed the error. Mouse clicking causes a loss of focus that triggered a calculation but use of the ENTER didn’t trigger this.

Final comment on development - it’s a different skill than testing. In fact, the opposite. Developers create things; testers destroy things - or try to. Back in the 90’s, this was universally recognized. But today, we seem to have forgotten this. It’s even worse if a dev tries to check their own code - like proof-reading your own work, a lot of mistakes slip through. It’s when testers fail to make the AUT fail that we say “it passed.”

I have written an article on the state of testing, which is tentatively scheduled for publication in the Summer of 2018.

1 Like
13

I dont know if the bold bit worked, so sorry if thats the case - I dont disagree that there are more developer roles, that’s a given. My point was more about the pay and respect part, where I don’t see that here in the UK.

It’s interesting that in the US that there is a difference in perception, and maybe this reflects the different levels of maturity around understanding the benefits of different roles.

Here in the UK, we are very lucky to have a great testing community that helps people realise that they are doing a worthwhile job, on a par with BA’s and Developers. The opportunities to learn new things and take them back to the workplace has changed people’s perceptions of what a tester can bring to a team - and Agile working has helped to embed testers into teams. Once a tester is in a team, the onus is on them to show where they add value - and I believe this is how testers have gained more respect, by pairing with other team members and showing what they can do.

I can feel your frustration as I read your reply - it doesn’t sound like a fun position to be in where it seems that the organisation is paying lip-service to testing. But take heart - there are many organisations out there that respect the testers craft :slight_smile:

14

Testing used to be this way in the U.S. (at least from the respect point-of-view), from my experience, when I started testing in the mid 90’s. The biggest problem at that time was that testing usually didn’t begin until most of the development was done. And I’m not talking about companies using waterfall either. As a contractor, I was hired late into the project.

The industry trend is to speed up delivery. Waterfall to RAD to Agile to CI (continuous integration) to CD (continuous deployment) - all done to speed up delivery. Test automation helps with this, but I feel it has gotten to the point where test automation has trumped testing, at least in the U.S… Test automation is seen by some as a way to replace testers. It might be my narrow world view, but it seems like the U.S. leads the way and others adopt. I hope other countries do not adopt this model.

I’m hoping the industry (software development industry) will recognize testing as a skill in and of itself and sees the need for both exploratory testers and test automators. Test automators write automated test scripts. The typical sprint length in the U.S. is 2 weeks, so they don’t have a lot of time, which means their tests are likely to be shallow. Exploratory testers would be the ones who “dig deep,” investigate and perform tests that can’t be automated - either due to technical or economic limitations. And who knows where exploratory testing will take them - that’s why it’s called exploratory testing. As the complexity of software increases, the level of testing will need to increase.

15

A point that hasn’t been raised is - even if you spend your own time learning coding and automation and get really good, if you can’t implement it in your own job (I.e. if you work for a consultancy at a client that doesn’t want to pay extra for test automation work) then will you be able to find a company willing to take you on with little or no commercial experience?

IT companies are notorious for dismissing the applications of developers and tech workers without years of the commercial experience in the stacks they are looking for, and from what I gather there is no shortage of hotshot test automators with great coding skills out there. I do wonder if the opportunities to break into test automation are greatly diminishing.