The following article is second in a series where I am talking real about "start in test automation". My goal here is not to disinterest anybody from trying to learn it. What I want to achieve is making anybody who considers starting work as testers as informed as possible. If you haven’t read it yet, I suggest checking the first part. Especially the introduction. It contains all the essential disclaimers and clarification of terms.
Similarly to the previous article, I will start with some popular myths. Then I will move to some aspects I don’t see mentioned as often to those who want to start.
The myths:
Note bellow point is paraphrases of actual statements that I have heard in the last few years. I modified them a little to keep authors anonymous; the message should be the same.
- Automation tester is only working on UI
- Automation Tester earns a lot more than Manual Tester.
- Automation is easy. It is basically writing tests in selenium, so if you know how to write checks, you can do it.
- I want to invest in my personal development.
- Automation is a way to go.
- Automation is required in most job offers!
- It’s a stepping stone to become a developer.
- Tester time is coming to an end.
- Automation Testers only automate.
Then I will cover some pointers that are not brought to light so often: Lots of companies don’t have work for you. You will have to fight for it. It can be tedious & frustrating. Devaluation Title matters
Ok, let’s take them one at time.
Automation tester is only working on UI test
This one is a kind of self-fulfilling prophecy. Yes, a lot of automation testers work only on automating UI test. Mostly because either the organisation believes this myth or testers themselves do. But in the most mature organisation, there is much more to automation than writing UI tests. Depend on the company you may write integration and even unit tests. You may also be responsible for Pipelines on CI/CD servers.
Even if you will write UI automation, there is so much here: from the design of the whole automation architecture, via test data, ending on test stabilisation.
Last but not least, usually you will be part of the typical development team which means you will also test manually. – I will discuss it in more detail in the next points.
Automation Tester earns a lot more than Manual Tester.
This tends to be accurate; usually, Automation testers can earn more than" typical tester". But the same is true for Security Testers, Performance Testers, Test Managers, Mobile Testers, Usability testers, Test Lead (not always), Test Analysts also earn more. Senior tester makes more than regular testers and regularly makes more than junior.
But the thing is all these roles require either time and experience to reach proper seniority or specialist knowledge or lots of talent/training. The same goes for automation which leads us to.
Automation is easy. It is basically writing tests in selenium, so if you know how to write tests, you can do it.
This one has too many issues to address them at once, so we will split it into parts. Strap on because this is a deep dive…
Automation is easy. (…)
No, it is not. Sorry but the truth is it is far from easy. Alan Page in past episodes of his podcast repeated again and again.
UI automation is one of the hardest pieces of code to write.
The truth is that tools like selenium IDE and MS Coded UI Test made it look simple. And yes those tools are quite simple to use, but they don’t give a great result.
Also especially UI automation is "flashy", at first whatever you do it seems you make significant visible progress. You can see how your tests are growing larger and larger. It is satisfying. In reality, you need to realise that there goes much more to writing automation tests. I think this is the easiest way to think about automation: It is programming you have a programming task to do – write a program (test) that does testing – I am not going to go into testing vs checking here.
Thing is writing a simple test is easy – if you know how to code. But the trick is to write test is the limited time that works and is maintainable, this is not easy. It requires a lot of developer knowledge. Don’t believe me? Just take a look at the series that started this blog. You will see a lot of consequences of harmful code in automation.
The Cost of keeping up.
There is something I don’t see discussed so often — the cost of staying up to date.
Working With automation, you have to stay up to date on:
- Testing Trends
- What’s going on in automation – new tools, new practices, etc.,
- What is happening in the software development world?
- What is even worse what is happening in front end world.
Especially the last one was chaos for last few years, it seems to come to some semi-stable state lately. But keeping up is hard, and if you want to stay relevant on the market, you have to keep up. Don’t believe me? I suggest reading Who moved my cheese. Some of you may say that it is contrary to ALAN principle(Avoid learning anything new) here is the thing.
It’s not about "avoid learning anything new", it’s about being tactical about what to learn.
Why is it important?
Cause well you depend on same developer tools as the developers. You have to be aware of what tools they use for CI/CD, version control and language versions.
As for testing, I think it is obvious; there are very few positions where all you do is writing automated tests. Usually, you will test in some degree of your time.
Counterpoint: Automation is getting easier.
Thanks to machine learning, and general progress in programming we have a resurgence of record and play tools most of them are much better than what we have seen in past. One of such tools is Mabl, and I love it.
There also are keyword-based automation tools; in such case, the company usually have one or two developers that write the keywords. Testers that are part of the development team just build test from those blocks.
There is GalenFramework which is easy to use.
But let me tell you this. Being able to use this tools doesn’t make you automation tester. Which lead us to:
(…)It is basically a writing test in selenium(…)
I think as you see it from my previous paragraphs, automation is much more than selenium. Just for UI testing the list of tools is long (some of them are based on selenium) Cypress, Applitools, Mabl, Selenide, Serenity, Puppeteer, and many many other
But most importantly, automation is not only UI! I would say even more! Automation on UI is most fragile, most expensive and less reliable type. In short, it is the least cost-effective type of automation. This is one of the reasons why the test pyramid became so popular to show that we shouldn’t rely so heavily on UI automation.
What Else is there?
The most popular: There is Automation on API level. (Integration Testing) Here we again have a whole lot of tools to choose from: RestSharp, Flurl, RestAssured, SoapUI, Pact.io, Postman…
I especially recommend Postman it is useful for manual testing and you can write simple automated checks inside of it. It is an excellent place to start with automation.
And If you want other types of automation: Contract Based Testing, Visual Testing are a few types that get more and more popular in the last few years.
Lots depends on the company.
I have heard that in quite a lot of projects Automation testers are only doing UI testing. In that companies Unit and Integration layer mostly belongs to developers responsibility. So yes, in those places you will probably do only UI testing.
(…) so if you know how to write tests case, you can do it.
I hope from previous points; it is clear to you that no, it is not. First Even if UI automation simulates actual user, you should avoid converting manual test cases into an automation test case in 1-1.
Why?
Because most of them are not written with automation in mind, for example, they can check many things at once – which usually is terrible for automation. They can be written in a way that automating them doesn’t make sense. For example, because lots of things they test, in automation should be tested on API layer or even on unit test layer.
Even when you want to automate on UI, while preparing the test cases, you have to take limitations and brittleness of the tools into account.
I want to invest in my personal development.
Sure by why automation? I have shown you a whole list of other option where you can go.
Again I don’t want to say * don’t go into automation*. But Motivation is important to succeed. And It is hard to stay motivated without a clear understanding of why you are doing it.
But you should learn how to code.
Coding is useful for testers even for those who don’t want to automate I have written article in the past on this subject (PL). So here is the summary:
- It will improve your communication with developers.
- Scripting languages are useful for writing simple macros for data creations.
- Understating how the application is written can improve your testing.
- It will open some doest for you, especially if the next point is true:
Tester time is coming to an end.
James Whitakker said test is dead a few months after I joined the testing world(2011). Back then, I didn’t want to believe it. But Looking at DevOps and Modern testing I tend to agree with their view that separate testing role is not necessary. Or at least not in scale it is now.
Note it is worth mentioning lately James Whitakker changed his stance a little.
Automation is a way to go.
This point is kind of connected to the previous one. But you have to realise one thing DevOps relays heavy on automation, but often it is automation written by developers.
###The future I see: To stay competitive companies need to deliver faster and faster. This is is only possible with a lot of automation. Since automation is not easy to write, and it’s importance increases only possible outcome is developers will be writing it. Testers role will be couching them how to test – there are already companies that work in this model. For example Spartez.
Even google in their book How google test software have stated the see Test automation role as a temporary one. That book is quite old, but I still recommend to read it to at least see how forward thinking’s it was. If you want more examples, Microsoft has Combined engineering teams.
So far, testing seems to be the safest in outsourcing companies – but don’t worry, changes will catch with them. I’ve already heard about customers making a request for SDET (in their interpretation tester who also can develop stories) instead of testers.
It’s a stepping stone to become a developer.
I said in the previous article if you want to become developer then go become one don’t go a long way around. But if you are Test Automation Specialist, I would encourage you to look into improving your development skill cause if my prediction from the previous point will come to pass. You will need it.
Automation is required in most job offers!
I don’t have statistics, but as far as I can see, it seems to be accurate: more, and more job offers require test automation or coding skills from testers.
Automation Testers only automate.
So here we come to the hardest questions of all" how much automation is in automation." The answer as with all question so far is it depends but there are few standard models. Let’s take a look at them:
Automation in the Development Team
The most common situation is automation tester is part of the development team he is responsible for both testing and automation. Depending on team maturity, other roles may also do testing and automation. Next question is when automation happens; the most common case is After both development and testing. If that’s the case, then your automation may be postponed from sprint to sprint due to lack of time.
Of course, the ideal scenario is when automation takes traits of TDD, Especially in cases when API contract and mocks are prepared at start. Then you can write automation before the developer finish writing story.
Automation in team – corpo version.
There is one variant of above, which is characteristic for much bigger companies, you also "write automation", but instead of writing code, you use preprepared steps/keyword/block. This is especially popular in huge companies that have the whole team dedicated to the development of the testing framework. And Testers in the team have very little work to do. Quite often if they don’t have a step, they need they can’t even write it themselves.
Again this also varies from company to company. It depends on how complicated their product is.
Automation Developer
In ancient times of waterfall, testers lived in a separate world of developers. In some companies Automation expert work outside of development teams. The only job is automating test cases. Honestly, in this case, I think the term Developer is more applicable than a tester.
Other things they haven’t told you.
Before I sum up this part, I have a few more things to say.
Lots of companies don’t have work for you.
That is something I heard, seen and even experienced a quiet few times. Company will hire you as a test automation specialist. But that doesn’t mean you will work with automation! I can’t explain what their reasoning was, but I have heard this story too many times not to share this warning.
And automation is a skill that gets rusty very fast.
You will have to fight for it.
Automation is not easy; I mentioned it time and time again. And as with everything you have to bring value to the team. If you aren’t able to do it, Then usually some manager will make the decision to stop investing time and money in automation.
Now to make it more complicated, remember that you have to do it in a sprint where developers regular don’t deliver on time. Yes, mock and contracts can mitigate this, but you need good programming skill to use them.
It can be tedious & frustrating.
At first, it is a rush of adrenaline: new tools setup framework New problems But as time progress, and automation becomes more and more stable. Tests become more and more the same. It can get quite dull. Then it is up to you how to change up the routine.
Do you want examples? Reviewing why tests failed it is routine you will do again and again, especially when you try to stabilise them. The only way to do that is to run them again and again, checking and fixing each and every failure.
Devaluation
As more and more people go into automation, you may expect the wages differences to go down. That is just the rules of the market. This video explains it greatly.
Title matters
This is, unfortunately, saddest part. In huge companies, quite often tittle matter and having automation in your tittle open quite a lot of doors. For example in a small company no matter the title, if you wanted to do some automation, they would let you (Assuming there was time for that) But in bigger companies where it is easier for a job as test automation expert. For Resources, you are just a number they don’t know and don’t care that you can code. If the project needs someone for automation, they will find someone with test automation tittle – the end.
To sum it up.
Automation is not the only specialisation that there is. But Compered to Security and Performance has the biggest risk of vanishing. It is not easy; it requires a lot of work to stay up to date. Same with proving your value – explaining the value of Testers is Hard, automation is even harder – and usually, people with this skill are much more expensive. It is also worth remembering that not every company has worked for you. Also, the amount of automation in your work will vary.
And For goodness sake: Selenium doesn’t equal automation; there is far, far more options and tools.
That all for this part
Ok, I told you all that you need to know now that you understand the consequences we can start talking about the journey join me tomorrow in next part where we will be talking about what and how to learn.

Edit: Part III had been released you can find it here.
Great article – again 🙂 I agree with all points and – what is most valuable for me personally – there are multiple great sources to get some knowledge and points of view about automatoin. Only one comment, I guess you meant „SOAPUI” instead „SOUPUI”.
Eagerly waiting for next article 🙂
Yeah, I think I was too hungry while writing that paragraph 🙂
Thanks for finding it 🙂 – Fixed
As for the next part, it will be a little different – I will be sharing some advice on how to learn. I will be debunking some myths there too, but the form will be different.
Also Thank you for coffee! (I assume it was you 🙂
Pingback: Testing Bits – November 3rd – November 9th, 2019 | Testing Curator Blog