So You Want to Automate? Becoming A Software Tester

Maciej Wyrodek, https://thebrokentest.com/, @maciejwyrodek

For at least a few years it has been a popular trend that more and more software testers want to automate. As a consequence, there are a lot of materials on how to start: blog posts, online courses, training videos, workshops, schools, and so on. They all promise you that you will be working on automating the tests soon. And there are quite a lot of unrealistic promises among them.

What is this article about?

In this article, I will be discussing myths about becoming a tester and "Automation Engineer". My goal here is not to discourage you, my dear reader, from beginning your software testing journey. What I want is to make sure that you have as much information as possible to make a conscious decision. In this part, we will discuss just software testing. Next, we will talk about automation. Then in the last part of the article, I will share some tips on how to start.

But before we start I need to make a few clarifications:

Titles, titles, titles

When I am using titles like Test Automation Expert/Specialist, Automation Tester, Test Automation Engineer or Automation Engineer, I am referring to the same general concept: a software tester who writes automation tests and has it in their job title. I will not go into details concerning what kind of tests are automated or how much of their weekly workload is dedicated to automation. We will talk about how much there is automation in automation, but wee will do this later.

Some links lead to articles in Polish

If after some link you see “(PL)”, that means I am supporting my claim with an article that is written in Polish – I have checked how Google is translating those articles and in my option, they are in a readable state.

Tech and IT

For this article, I will be using term “Tech” and “IT” as synonyms.

Now we can start!

Dysfunctions

In most cases, I will show you a common situation coming from a dysfunctional team. There are of course plenty of healthy teams out there and you may be lucky enough to be part of such teams throughout your career, meaning that you won’t ever face any issues discussed here. The problem, however is that there are a lot of teams which have some dysfunction. So it is highly probable that you will see at least few of the them in real life.

Data

I am mostly basing my observations on my own experience, observations of threads on a few forums, discussions on different conferences and short searches on IT jobs boards, as well as on whatever information I could get from my friends in HR of different companies.

Becoming a software tester

Why software testing? The myths:

Below is a shortlist of the most common misconceptions I have heard about testing, which are being repeated to people who are getting into testing or just got into it.

1. It is full of money.
2. Getting a job as a tester is easy.
3. Testing is easy, anybody can test.
4. It is an easy “Nine to Five” work in a comfy office.
5. From Tester, you can become a developer and earn even more! First, I will go over the myths above and then we will talk about some of the aspects that I don’t see being brought to light too often:

• Tester as a failed Developer
• The disrespect
• Tester vs Developer conflict

IT is full of money

Yes, you can earn a lot while working in IT and there is a high job demand, but there is one issue. Looking at the history of capitalism and market trends, some people (including me) see current IT as a bubble, like the dot.com bubble. That means at some point it will burst. Who knows when? Who knows how and why? One thing is sure: the later you join the more probable is that you will be hit by the burst. Radosław Smiglin 4 years ago wrote great articles on this subject. (PL), If you prefer an article in English, this one addresses a similar issue.

I was expecting it to bust within a span of 5 to 10 years… and I made this prediction five years ago. Today I am not as confident to give ranges as before. Some say this is not a bubble, that it is a revolution similar to the industrial one, but I am still worried, as some signs make me think otherwise. One example was the considerable dips in NASDAQ near the beginning of the year for tech companies. Other cases are risk connected to the AI

Having said that, I have to admit that, as far I know, there wasn’t ever a better time in Tech than now. There is a lot of work, so if you are already in the system, finding a new job should be reasonably straightforward. At least until you reach higher seniority/expectations/narrow specialization, then the choice is getting smaller and smaller. There is a lot of capital coming to IT companies (remember what I said about the bubble?). So it is relatively easy to get a well-paid job. On the other hand, somehow there is not as much opening for juniors (PL). Practically every company wants someone with experience.

How much a software tester earns?

This is yet another important information coming from surveys: here (PL) and here. IT doesn’t look so bad, but keep in mind that those are declarative surveys, which means the answer is not entirely trustworthy. Plus it is an average of different work models, cities, etc.

Testing quite often is considered one of the low skill IT jobs (more on it later). Which means testing also has one of the lowest pays (within the IT). In lots of companies, the glass-ceiling for test jobs is actually quite low.

Besides that, there are many variables that affect wages: company’s capital, current demand for this role in the company, company’s policy, etc.

Getting a job as a tester is easy

This was technically true at a time. The best way to think about the current Tech state is this:

According to Wikipedia gold rushes have a life cycle. At first, you can find gold with a gold pan and no training. Anybody lucky enough to be at the right place at the right time can find the gold! But as the source gets depleted, you need more and more specialized equipment, and advanced training & knowledge to use it. This also means that the whole operation is getting more and more expensive.

The same thing happened with IT at the beginning when testing became a separate discipline. Anybody who could operate a computer could become a Tester! Only a few people had any idea how to test. Back then it was enough to "just click around" and see what was happening! Although to be fair, not too long before that era, anybody who could operate a computer could become a developer.

But as the field matures and the easy goalpost are long behind us, similar to the gold rushes, an era of unskilled labor has passed. Note that doesn’t mean you won’t get a job having no skill, as there is still a need for fresh blood. It means that the need for unskilled and inexperienced people is much lower than it was at the beginning. You have to realize that you will be competing with a fresh batch of grad students that leave universities every year. They have lots of optimism, low expectations, will to work for just experience, and if they are from the IT department – they also possess technical background. I will talk about the importance of it in the following points.

Do you remember what I wrote in the intro? There is a whole industry that bloomed around getting people into testing. This should show you how many people want to get into testing. The only problem is there is a limited number of Junior positions opened.

Testing software is easy, anybody can test

Yes, “monkey testing” is easy: you just have to click on something and see if anything strange is happening. However, this is neither efficient nor desired by companies.

There is a lot of theory behind testing. Testing stopped being a new discipline long ago. There are many testing techniques and methods! To give but a few examples: Equivalence Partitioning, Boundary Values, Path Coverage, Condition Coverage, Risk Based Testing, Rapid Software Testing, Session-Based Test Management, and the list goes on.

We are talking just about "actual" testing, and yet I still have barely scratched the surface of the subject. And there is a lot of other things to do before and after we test something. To name just a few: estimations, test strategies, test plans, preparing test data… the list goes on and on.

Why testing seems easy?

This is a question I have been asking myself for a long time. I have few theories on that.

A lot of testers from the gold rush era are still around, and some never progressed and improved their skills. What is worse, some of them went into consulting and are loudly opposing any new ideas. Unfortunately, other branches of IT sometimes aren’t taking them seriously so it helps to spread the vision of testing being simple.

We are divided. I used to joke when Two testers meet then you will get five definitions of what testing is. And since we have difficulties in agreeing what testing is, how can we explain it to others in a way that they understand?

To make it even harder, it is difficult to prove the value of testing. It is easy to show the importance of developers, but the value of testers is much harder to explain.

The “nine to five” job

This point is mostly correct, a lot of IT companies spoil their workers. Game rooms, sport rooms, massages, free fruit, work from home, etc.

However, it is not always like that. There is a lot of stress especially close to deadlines (for example in scrum you can have a deadline every two weeks!) and especially for a tester. It happens very often that development delays result in shortage of time designated for testing. So you may work calmly for the first few days and then one day closer to release end up on a colossal overtime. Tech has one of the highest rates of burnouts. Long hours do happen, how could they not if you may be the only tester in the team? Sometimes due to releases, you may work at the weekend or late at night. For example, in Dell, quite regularly, we had releases that were taking the whole night. There are even some companies that will avoid paying you extra for that. You will be able to take the time spent on overtime off, but not get any cash for that.

This is slowly changing, for example, thanks to DevOps, the releases are getting "simpler and easier" to manage. Basically, in DevOps the goal is to have fast, frequent and safe releases that can be performed within regular working hours. But DevOps also put the responsibility on the team for production issues, so it brings on-call duty.

Working in a worldwide environment

There is one more aspect that can affect your working hours. If the company has many offices in different times zones or its customers are from all over the world, it’s possible that you will have to work in unusual hours, either from time to time or regularly.

Working in such an environment may also require a lot of traveling.

From tester I can move to better roles

As far as I am aware, the most popular paths people from outside IT want to go through are : IT support -> Tester-> Developer Tester -> Analysts Tester -> Automation Tester -> Developer Tester -> Manager

If you want to be a developer, then don’t waste your time on becoming a tester, just go and learn the skills required to be a junior developer. Yes, there is quite a skill overlap. But here is the thing: the most important skill for a developer – coding – is hard to foster as a tester. You will need to put a lot of your private time into it.

Yes, you can learn a lot of stuff that is common for tester and developer:

• tech jargon,
• working methodologies & Development Life Cycle,
• interactions with Project Managers, Customers and Business in general,

Furthermore, you will be able to observe developers at work But here the similarities end and there is a huge array of responsibility that goes under a catch-all term "writing code" that testers are not doing.

I will let you on a secret: Michał Buczko claims that from any role you can get to any other role. But no one will give it to you on a silver platter, you will have to fight for it. And why waste time going the round way?

Plus you won’t believe how many people are stuck in their role as a tester. With time, it is harder to commit to learning in order to switch roles, especially once you actually earn good money or are overwhelmed with the actual work for which you get paid.

Companies have upskill programs!

Yes, but here is the kicker, no one will hire you as a tester if they realize you think about it as a stepping stone to software developer. As a technical interviewer, I can tell you this: even if you don’t tell us it is your goal, we can figure it out. Remember, usually there is some HR person that will talk to you trying to figure out if you fit the company. They have a sixth sense for figuring this stuff out.

Upskill is not for everybody

Listen companies want to invest in their people and increase their skill set. Sometimes, especially for developers, they even care for getting them some certifications.

But the company has to see a reason to invest in you. You have to show some potential that it is worth investing in you. When it comes to upskilling and mentoring of employees, my boss often asks this question:

What are they doing on their own?

A company isn’t there to give you stuff. A company is there to make money, and they will invest in you if they see a good chance of return on investment. Doing something on your own is the best way to show it to them.

So yes, you can move to other roles, but it not always easy, and if you think you have what it takes to work as a developer, you should aim straight for it.

Issues that aren’t talked that much

The paragraphs below are something that I’ve heard being discussed over and over among testers. but I haven’t seen them being brought up to newbies’ attention too often.

Tester is a failed developer

It happens that a grad student who fails to find work as a developer goes into testing – I am an example of that. I wanted to become a developer, I tried over and over again, with no success. But then a kind soul after the interview said that he sees the potential in me to become a tester and maybe I would like to come for one more interview – this time for a tester role.

In the past, I saw a lot of articles saying that such approach is bad. Their argument is that the company doing it this way will, instead of getting testers, end up with bad developers who are testing. I haven’t heard this argument in years. So much that I can’t find any article that talks about it.

But the fact is, even if you get hired this way – they hired you because they see your potential as a tester and not because they want you to become a developer one day.

The disrespect

Testers are quite often treated as second class citizens of the IT world.

I think this year I have heard the term "Tester (Testress?) a wife of Developer" at least ten times. With the claims like "She became a tester because her husband is a developer" which is actually quite harmful.

I too had to go through similar superstitions a few times, in some places when I started working I had to earn the developers’ respect because at the beginning they were looking down on me.

In organizations where the process is unhealthy, you will see this disrespect of tester role a lot. Testing activities would be at the end, often starting late because the developer couldn’t deliver on time. Testers not invited to the meetings or not involved in some activities as "They will not bring technical knowledge to the table". Same with testing being a scapegoat. If something fails at the production in those organizations, you can hear the question “why testers didn’t catch the bug?”. No one will ask why the developers put it there in the first place. Or what can we do to catch it sooner next time.

As for the absolute example of testers being the second class citizens in IT, look no further than Game industry and RockStar same issues you see there you can observe in other IT companies. That is why I would recommend reading Jason Schreier Investigative Reports and Kotaku Development hell articles.

Yes, there are places that are much better than those described above, but they will search for experienced employees. So there is a higher possibility that at the beginning, you will find yourself in one of those problematic environments (due to their broken process and quite high employee turnover).

Tester vs developer conflict

Again it depends on the place. If a company is working well and has a good culture, there is no friction between testers and developers. But just because of the very nature of the testing job, it is easy to have a conflict on the line of tester – developer. Just look at the simple amount of articles on this subject.

Putting it all together

In this part, we tackled some myths connected to being a tester, Starting from wages and job availability – which we compared to the gold rush. We also addressed the myth of simple, easy nine to five job. The list of dysfunctions you may encounter goes on and on. We barely scratched the surface. I doubt you will see all the issues at once, but I am quite sure in you will see quite a few in your first years.

Let’s talk automation

Now I will start with some popular myths about test automation. Then I will move to some aspects I don’t see mentioned as often to those who want to start.

The myths:

The points below are 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.

1. Automation tester is only working on UI
2. Automation tester earns a lot more than a manual tester.
3. Automation is easy. It is basically writing tests in Selenium, so if you know how to write checks, you can do it.
4. I want to invest in my personal development.
5. Automation is a way to go.
6. Automation is required in most job offers!
7. It is a stepping stone to become a software developer.
8. Tester time is coming to an end.
9. Automation testers only automate.

Then I will cover some pointers that are not brought to light so often: a lots of companies don’t have work for you. You will have to fight for it. It can be tedious & frustrating.

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 organization believes this myth or testers themselves do. But in the most mature organization, there is much more to automation than writing UI tests. Depending 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 stabilization.

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 a 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 realize 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 Galen Framework 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.

A lot depends on the company

I have heard that in quite a lot of projects automation testers are only doing UI testing. In that companies, the Unit and Integration layers mostly belong 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. 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, but 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 doors 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 that 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 realize 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 its 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 have already heard about customers making a request for SDET (in their interpretation tester who also can develop stories) instead of testers.

It is a stepping stone to become a developer

I said previously that 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 software 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 is 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 – corporate 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 prepared 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 the 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 and frustrating

At first, it is a rush of adrenaline: new tools setup framework, new problems, but as time progress, 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 stabilize 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, the 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 the Human 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 specialization that there is. But compared 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 software 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.

Let’s talk about some basics of learning

At this point, I hope you realize it is no piece of cake and the road to IT is complicated.

I will give you a few numbers:

I have studied computer science. During my time at university, I have spent more than 2000 hours per year writing code or learning about it. Both in sessions labs and at home.

It was roughly 8k hours over five years.

And yet I wasn’t competent enough to find work as a software developer!

Granted, that number is a little bloated, I had other subjects to learn too, but it is there to show you the scale.

I have another number to give you

Not too long ago, a mentee at my company finished his mentorship going from Quality Engineer to Junior Automation Quality Engineer.

He had quite diligently tracked time he spent on learning.

And his value was around 300 hours over eight months. And he is still investing his time into it.

I won’t hide it; he still has a long way ahead of him. But he knows enough to start working with automation. But I think this is a low number – he had a great mentor and a lot of talent.

Why I am writing about it?

To make it clear for you. No certificate, no 1-day course even, no week-long course will be able to prepare you for actual work, at best will give you basic look and feel.

You have to put your own work into it. And it is a lot of effort.

You have to not only learn theory but also gain some practice. Yes, you won’t get real work experience without working, but you can do some testing on your own, trying to put in practice what you have learned.

There is also another question here:

How did we manage to stay motivated in all this time?

I think the best answer for this question comes from Yahtzee in his Dev Diary

I identify as creative, (…) the reason I can do it as my job is because I was doing it years and years without pay of recognition. And as such had enough practice to go to a somewhat professional level. So if you want to earn a living as creative, I would say you already have the wrong attitude.

It goes down to passion. Some of us had passion from the start; for others, they discovered that Automation/Testing fascinates them somewhere on the road. That is why if you are interested you should give it a try.

Maybe you will find a knack for it but if you are looking for it only as a job for easy money. I doubt you will find resolve in you to see this path through.

Know yourself

First thing, first

Observe yourself and observe how you learn. Each of us has different ways of learning what works for one person may not work for you.

You need to understand how you learn:

• Some need someone to provide outside pressure and support to help them learn.
• Others need their own pace.
• Some need lots of theory.
• Other need a lot of practical examples.

I recommend reading about Kolbe Cycle – it is not the most accurate tool, but it is better than nothing.

Example – How I am learning

It took me quite a lot of time, but I have found my rhythm:

• I can’t learn dry theory – I have to have some experience or ideas in my head that help me connect it to my existing knowledge.
• Which means I have to do some practice first, either entirely on my own or following some tutorial.
• Then I can finally start reading the theory behind it.
• There is here also my hubris at work: Often, I am trying to do too big projects at the start, which leaves me, that I am unable to do what I want. This is why I have to watch myself and avoid taking too much at once.

Know when to start

I will tell you this: you will need to build some technical knowledge about how computers work. Believe me; this will also be useful for you as testers.

For writing code, it is crucial. Sorry, but even high-level programming languages are still close to the computer. To write efficient code, you have to understand how computer memories work, how to read it and write to it. What types of data structures we have what the pros and cons are. Speaking plainly, you need to learn how "computers think".

Yes, you can write code without it, but here is the issue writing code in reality is parsing a theoretical "image how something should work" from your head to code. The more you know how stuff works the idea you create will be simpler to move into code.

Plus increasing your technical skills is also useful for your everyday testing.

There is a lot here, but for a starter, I recommend this course.

Do not worry “it is not the language I want to use” – this course is about computer science, which is universal language. After you finish you can select a programming language and learn it

Then when you fill quite a confidence with your coding skills, you can move to automation.

Technician vs Engineer

My father likes to say:

Technician is someone who was thought how to do something, they know few solutions that work and how to use the tools, but when the problem arises for which they don’t know how to deal with it, usually they will be stuck. Engineer, on the other hand, understands why something works know the theory behind it, so they can think of a working solution even if everything else fails.

I love definitions from this article:

1. Engineers rely more on the theories of their sciences, while technicians focus more on its practical application.
2. Engineers are the problem solvers while technicians are the actual doers.
3. Although not applicable to all situations, the engineers are those who have obtained a degree which often requires a four-year course while technicians only need a shorter diploma course and additional training.
4. Because of the level of education, engineers are often better paid than technicians.

Why I am talking about it?

I tried to find a job posting for a software test technician. To my surprise I found a lot of them.

But in most cases there was 3-4 times more offers for engineers.

There are other popular titles for test jobs: Test Analyst and Tester (this title is too catch-all to check number for it.)

My point is the job title itself says a lot. Companies expect from you to have the knowledge to problem-solve issues, and it is hard when you don’t have fundamentals.

Don’t overstretch yourself

This is important. At the start, try different tools and languages! But at some point; you will have to choose what to learn.

So try a few languages. But then choose one and learn. Don’t doubt that you chose the wrong one. Later, when you have basic proficiency with it, learning’s next one will be much easier. The poor choice here is better than no-decision.

Not too long ago I found this ebook by Ali Spittel dedicated to those who want to learn programming (and you want) I recommend reading it. She goes into more details in a lot of issues that I am mentioning in passing.

Be patient

Yes, UI automation is cool; it is easy to see what progress you are making. But it is the same as with building a home. You spent a lot of time working on the ground, without seeing any noticeable progress. But when you finally leave the ground, progress skyrockets quickly. The same concept applies here.

Online tutorial

Lots of people will also tell you that there is everything online, for example, on plural sight and Udemy. While preparing for this article, I have seen the following statement a lot:

Don’t buy this course when you can have the same on Udemy for 10 USD.

Here is the thing you need to understand what you are buying.

First, you are buying a video. You are not getting access to the teacher. If you have any question because you don’t understand something, you can’t ask them. In theory, you can ask the authors, but it is high probability they have moved on to the different project and won’t care to help you. Of course, your mileage may vary.  I talked with few authors and most told me they are willing to help, but they had to draw the line at some point.

There is this excellent parody of programming tutorials. It hits a little too close to home. I have seen so many tutorials online where I couldn’t follow what presenter was doing. Either the tool has changed, the layout is different or some options were removed. Even if you make some small mistake copying the code, you are alone with finding and fixing it.

Just to be clear resources like Udemy, YouTube or Pluralsight are great, but they have their limits. I would encourage you to give it a try but be aware of their limitations.

Other online resources

I love sites like code wars and hacker rank – they are great for practices. My friend completely learned python only doing tasks on code wars. Thing is she knew how to code and she was only learning a new language. Trying to learn this way won’t give you theory. Which at the beginning won’t hurt you but when the time comes to design something on your own, you will feel it.

But to get fluency in the language, I already said the practice is most important, and this place will give you a lot of practice.

I have heard about online courses with teachers who can answer your questions and review your work. But I haven’t much contact with this form. So I have no option on them.

Easy to check

The greatest thing about online resources is how easily you can check if the given course is worth your time or not. Lots of them have either ratings/reviews or some free trials. With some patience, it is hard to buy a pig in a poke.

Books

Books are a great source of knowledge, and you can learn a lot from them, however they share a lot of problems with online courses: the material can get outdated quite fast.

I would be cautious with learning tools from them. But they are amazing for learning the fundamentals of computer science and concepts connected to it. If you are looking for some inspiration, I have some recommendations here

Courses, labs and workshops

Don’t believe in stories that they will teach you how to automate in the day. Sure these courses are a good overview, but unless you have high skill on the entrance you won’t go as far as they promise.

With courses, you need to check the agenda. Check what is there if the course is short and agenda packed – I would suggest avoiding it.

There is another risk with courses; it is much harder to find one that is worthwhile. Now that we are in the gold rush of automation, everybody wants to get they share by providing services to others. In this case, teaching them skills. (I am one of those people)

The real strength of this form is in real-time interaction.

If you have a problem or some question you can usually ask someone will help you either the "teacher" or some other participant. This is the greatest asset of workshops! The ability to learn from each other and the possibility to tackle problems in the group.

Postgraduate Studies and Bootcamps

This is another option difference compared to the previous point is the length, here you have a much more complex overview where you can learn much more.

The biggest issue is this form is one of the most expensive and most time-consuming. I think outside of mentoring (and normal full-blown studies) this form is most effective.

But unfortunately, since it is the biggest investment, it requires a lot of checking beforehand.

Why? Cause there is a lot of poor quality cash grabs out here (same for all other forms but here I think it hurts the most).

Some issues that I heard from unlucky people are:

• Lectures who are saying straight out incorrect information
• Outdated subjects

The mentor

I think the best way to learn is to find yourself a mentor. Some companies have official programs. But always you can talk with some developers and ask them for help – for example, "teach me something/answer those questions and I will buy you lunch/beer".

This is how I did it, when I started my journey. I had two great developers nearby, and I have learned a lot by asking them questions.

Thing is it is hard to find one. Another issues is being a mentor is not easy, so yo may find some bad one.

Whatever you do – pace yourself

At the start, you should do some tutorials courses/etc. But sooner or later you will have to start to work on real problems.

But be careful – this is a place when most fail. They try too difficult issues before they have the skills necessary to tackle it. So if you haven’t written anything yet don’t try to write huge working application at the start.

Maybe some simple command-line calculator will be good. And then maybe some phone-book.

The difficulty is important if it is too high you will burn yourself.

You have to have pet projects and work on them! Best yet put them on GitHub or somewhere so they will be visible.

Courses, workshops etc. will not guarantee that you will get a job!

This is something I have slightly touch in previous points. This year, I checked hundreds CV, and I did close to 50 Technical interviews. I have also talked with technical interviewers from other companies.

There is one terrifyingly clear thing – We don’t trust online courses and small workshops.

For us the fact that candidates have, few Udemy course or some workshop in their CV means very little because most of the resumes we see have those. (And/or ISTQB Certificate). And those people were not doing well on interview.

But it doesn’t mean that course was bad. Usually outside of doing the course people do nothing to learn more or practice skills they learn, so whatever they learn will go away soon.

The thing is, it is possible we became biased. We have seen so many people who thought that they could do one day workshop and become tester that we subconsciously are treating all people like that.

This is why you need to standout! Right now, the best option is to have a portfolio that proves you are learning that you went for this course to gain skill and knowledge.

Hire for attitude, train for skills

There is a slow change happening in the way companies looks for candidates. Describe in this catchphrase "Hire for attitude, train for skills." No, that doesn’t mean that you will be hired if "you know nothing". But it means that companies hiring priorities are shifting more and more in the direction of checking if you are culture fit. And this means a completely different thing for each company. To give you some example they may be interested in:

• Your integrity
• Your ethics
• Ability to learn
• Self-organization.

The thing is that it doesn’t mean that the company will always want you to have them "high" especially integrity and ethics if the popularity of the dark patterns is anything to go by…

To cut this tangent short: if you find the right company for you, you may find a job without any skills, but that won’t be easy.

Don’t limit yourself to one way of learning

I will reiterate on it one more time, you have to experiment and find a way of learning that will work for you.

But here is the thing – your way doesn’t have to be pure. – ergo only Udemy, only courses, only book.

I will use myself as an example:

• I mostly learn about new tools ideas from podcast and conferences.
• If I want to do deep dive is some methodology concept, I will get read a book on this subject.
• If I want to practice codding in some programming language, I will do either Kata or few challenges on CodeWars.
• If I want trouble with some concept or idea. I will experiment to see how it works – for example, I will write some code.
• If I want to want to sort my knowledge on some topic, I will prepare a presentation or blog post on a given topic.
• If I have problem with some trivia (can’t find the option in the tool, don’t remember syntax) I will first check documentation then a search engine.
• I have no patience for Udemy, Pluralsight and YouTube – most of the pacing of most of the videos don’t suit my learning style. Having said that I am using them from time to time.

It may not for you

I don’t want to be elitist. For a long time, I believed that programming and coding could be taught to anybody. I still think that, but I am no longer sure that everybody can achieve level proficiency that allows for working with code. It is same with everything else hard work is a massive part of the equation, but some natural affinity is also needed.

That why Gallup Strength finder suggest we should work on the thing that is based on our strength – we can do anything but the further we go from our strengths the more effort we have to put in, and it can lead to burnout.

Some time ago I found this quote:

I am of extremely average intelligence. On the absolute top of the bell curve, looking down at the rest of you. I am extremely tired of the whole attitude that anything is possible if you just put your mind to it. I put my mind to it. That is how I got through CS in university. I worked at least twice as hard as the people that said just put your mind to it and then cruised through even the hardest course without ever studying more than an hour a day and then doing an all-nighter to get an essay in.

Working hard as hell to understand what some low-effort-high-intelligence "just put your mind to it" brat understood as soon as it left the professor’s mouth is hard. It just shows me again and again that I drew the short straw in the gene lottery. I have to work a lot harder to do the same things.

I am not saying you shouldn’t try – you always should, but there is no shame in deciding it is not for you.

TL;DR Learning

1. Experiment! Check if IT is for you, Don’t be afraid to change your path it isn’t
2. Know how you learn and select materials that will work for you.
3. Build your technical knowledge.
4. Learn how to code.
5. Learn how to automate.
6. Practice, practice, practice

Thank you for reading!

In this article, I have discussed some aspects of starting to work as a software tester, concentrating on stuff that is not often shown to those who want to get in. We started with a discussion of myths connected to work as a tester, the we took a look at work with automation and its misconceptions. Finally, we discussed learning.

This is the longest article I have written. It took a lot of work doing research and putting it in a coherent form. I feel I will reiterate it once more; I don’t want to dishearten you. But I want to make sure you know what you are getting into. I think this clip from Scrubs explains why I am doing it.

I hope it is helpful to you and good luck! Let me know if anything here helps you. I would like to thank Java Girl, Kamila Polańska , Jan Kędziesrski for reviewing different draft and offering their feedback. You have no idea how important it was.

This article is based on 3 blog posts that were originally published on https://thebrokentest.com/so-you-want-to-automate-part-i-becoming-a-tester/, https://thebrokentest.com/so-you-want-to-automate-part-ii-lets-talk-automation/ and https://thebrokentest.com/so-you-want-to-automate-part-iii-lets-talk-learning/

---

Test automation and software tester articles in Methods & Tools

Test Automation Strategy Out of the Garage

Choosing and Managing the Ideal Test Team

Related Software Testing Resources

• Software Testing Magazine
• Software Testing Videos and Tutorials

---

This article was originally published in January 2020

Click here to view the complete list of Methods & Tools articles