This is 3rd part in a series of articles dedicated to people wanting to start their adventure with automation. This time we will discuss the process of learning. You can read previous parts here and here.
Compared to previous articles, I won’t start with myths. Yes, We will discuss some on the way, but this is the only part where I am not only ranting, but I am offering some solutions. Similarly, this article is not how to start the guide. It should be treated more in the style of tips and tricks.
I am both leading paid and free workshops teaching people how to code and automate. And from time to time, I sell my services as a mentor.
This makes me both qualified to write on this matter but unfortunately makes me also aside. I am not here to sell my services. I am doing it from a sincere desire to help. That is why you won’t find in this article any link to my services.
Let’s talk about some basics of learning.
At this point, I hope you realise it is no piece of cake.
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 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, 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’s 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’s 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.
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.
But 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 sdould 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:
Engineers rely more on the theories of their sciences, while technicians focus more on its practical application.
Engineers are the problem solvers while technicians are the actual doers.
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.
Because of the level of education, engineers are often better paid than technicians.
Why I am talking about it?
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 dby 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.
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.
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 cause 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,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/Pluralsight are great, but they have their limitation. I would encourage you to give it a try but be aware of their limitation.
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’ve 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 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 /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
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’ve learned a lot by asking them questions.
Thing is it is hard to find one.
Another issuse 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 phonebook.
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. won’t 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 practise 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.
That’s 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
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, Prularsight 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.
Before I summarise the whole series Lets sum up this part:
- Experiment! Check if IT is for you, Don’t be afraid to change your path it isn’t
- Know how you learn and select materials that will work for you.
- Build your technical knowledge.
- Learn how to code.
- Learn how to automate.
- Practice, practice, practice
Thank you for reading!
In this series of articles, I have discussed some aspects of staring work as testers, concentrating on stuff that is not often shown to those who want to get in.
In the first part, we discussed myths connected to work as a tester.
In the next part, we took a look at work with automation and its misconceptions.
Last but not least, in this part, 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.
Especially I would like to thank, the two great people who bought me coffee. You have no idea how much it means to me that somewhere out there, someone find enough value in my work to give me a tip.
Fixed broken link to course– Thank you Dominik for finding it 🙂
Fixed the idiom – in English, there is no „Cat in a Bag” – there is „Cat out of the bag” and „a Pig in a poke” and „Cat in the sack” Thank you to Peter Brookes-Smith for explaining the difference to me.
Fixed pronouns, Thank you Ileana for bringing it to my attention.