So you want to automate?

For at least a few years it has been a popular trend that more and more 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 series about?

The following post is the first of a series of articles where 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 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 testing. Next, in the second part, we will talk about automation. Then in the last 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, Automation Engineer – I am referring to the same general concept – a 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 that in the next article.

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 series, 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.

Why 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 specialisation, 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 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 specialised 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 labour 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 a need for unskilled and inexperienced people is much lower than it was at the beginning. You have to realise 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 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 BasedTesting, 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 travelling.

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 dev. 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 realise you think about it as a stepping stone to dev. 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 dev 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 organisations 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 centra in you will see quite a few in your first years. I hope that this article showed you that it is not always so easy. If you want to become a tester, there is a long, tough road ahead of you.

That all for this article

So I wrote a lot about testing and tittle of this article is "So you want to automate?" Its time to fix it! In the next week, I will release the next part where we will talk about automation: The good and the bad and the mundane of working with test automation.