I planned this personal page/blog for quite some time now, and the biggest question I faced is - where do I start? Do I start spreading my gospel on how to improve Page Object Model? Do I go after some common mistakes in the process? Honestly, I got stuck there wanting to go after the big things, start flame wars engaging discussions, but on second thought, why not start at the beginning, where it all starts. Should I get into it? How?
Most of this comes from my experience and what I did, or wanted to do differently, and from the experience of the people I worked with. Seeing how many different backgrounds are present within my circle of QA friends, acquaintances and connections, I hope that I can persuade someone that software QA is the right place to be/start/visit, or at least give someone a wake up call to go after their dreams as far away from it as possible. (Delusions of grandeur surface again)

A short disclaimer: each company has its own criteria for hiring, and their own definitions of what a good candidate is, what follows is a generalization and is not aimed at any specific company or job ad. I will present my point of view on some of the common roles and the criteria that I would expect from a good candidate (not a perfect one).

Who this is for?

So, now that I’ve wasted some of your time on the needlessly long introduction (which would better fit someone with an already established audience and a more conventional sense of humour) I will now try to dissuade you from reading it further if you are in a pinch.

This is aimed at beginners, and by that I mean people that haven’t had any work experience in software QA, or software in general. The field is generally welcoming to a wide variety of backgrounds and experience levels, so if you are planning on a big career switch from a non-software field into software or you are a fresh graduate (any field/degree level), software QA can be a welcoming place and a good starting point for your future growth.
If you do have some experience, but are having trouble breaking into the field, or you are interested in making a switch from another software related role (tech support, for example, is often mentioned in this context), this might give you a nudge in the right direction towards that goal.

Roles and requirements

As with any other field, there is plethora of different roles that one can take on. I will present some generalizations of each role and a base skill set (tech fundamentals, general traits). I picked these three (they might be going by different names depending on the company) because they are most likely to have a beginner level job ad on offer.

Software tester - manual

Starting off from the most common one (and the one that many consider has the lowest entry requirements, I am not that bold). Manual tester, sometimes called QA Engineer or Software tester, is the starting point of QA. From this role you can advance to other roles listed, but also diverge into other fields, like Project Management, Scrum Master roles, as well as all other QA roles, and similar.
Even though some (including Uncle Bob himself) consider this role to be obsolete and unnecessary, it is still the most common one and, with all available paths, it remains quite popular for potential job seekers (my first job application was for a Software Tester Trainee role, but I was called in to interview for another role).

At the starting level this role can be described as following a test scenario and reporting your findings, but may involve other duties as well, like creating test documentation, writing test scenarios, selecting candidates for automation, error investigation, running tests and analysing and reporting test results and others.
The role is time intensive, which means that you will be working with a time constraint (e.g. you are testing new features as they come in and have to finish testing before the agreed deployment date). This might involve working overtime, and can cause stress in some environments, so please be aware.
Most of the day-to-day tasks are well defined and there might be little to no space for the creative side to be engaged.

So, what are the basic requirements? The main focus will be on personality traits and soft skills like team work, communication, friendliness, while technical requirements will be secondary. Being able to describe an issue in person, or in writing goes a long way to save time needed to make the correction and bonding with the team reduces it further as the QA is not perceived as the ENEMY (believe it or not, there is an anecdote often told about an incident in which developer chased a tester around the office insisting that it was impossible to find a bug in his code), so the development team is more likely accept the criticism as neutral, or in good nature (this statement can best be applied to agile software development, QA being part of the product development team or having access to it is not a thing for all companies).

When it comes to technical requirements, general understanding of technology is the most important. Lets say that the company you are applying for works on web app development (as these are the most common, and also the ones I have experience in), in that case some basics would be HTML and CSS. You don’t need to be an expert on creating websites, but knowing the structure of HTML and being familiar with browser DevTools (right click on a page and select Inspect option) and finding potential issues there is a big plus. As secondary, basic knowledge of network request types, headers, bodies and response codes can help you stand out, and lastly any programming language and framework familiarity (JavaScript is a large plus) is beneficial, but not required.

Test automation

Test automation engineer, also called QA Engineer (yes, that role can mean multiple things and is the one I was called in to interview for when I applied to the Software tester job ad), Software development engineer in test (SDET for short), QA developer (rare and somewhat unclear), is a role in which you will be responsible for automating test scenarios using a test framework.

This is the second most common QA role, and is more technically demanding than the Software tester role, but involves less soft skills. The two roles often work in tandem where Software tester selects automation candidates and moves responsibility to the automation. This streamlines the regression testing (simply put - testing of already existing features when new ones are being deployed), and ensures that new changes don’t break the already established ones. Due to this difference, Test automation is less time intensive, resulting in less restrictive deadlines and more time for creative work (improving existing test framework, personal improvement, etc).

At the starting level it can be described as updating and maintaining existing automated tests as well as writing new tests, running tests and analysing and reporting test results, other responsibilities that can come later on are developing and maintaining test automation framework, setting up test runs in CI/CD pipeline.

The requirements? Well, I will focus on web development companies again (see the previous mention for the reasoning), and focus on automating browsers. Soft skills for the manual role still apply, but are less in focus. As there are many frameworks/languages to choose from, I will focus more on programming/scripting principles than specific technologies. Base of it all is, at least, being familiar with a programming language and a testing framework/process. Since most of it is based on automating test scenarios, knowledge and understanding of business readable (this is how it is described, I am not joking) description language, such as Gherkin/Cucumber is a big plus. There are also some common test automation principles which you should be familiar with, mainly Page Object Model which consists of representing a web page as an object and abstracting the interaction with web elements (it sounds complex, but once you see an example it becomes quite clear and natural to use). Another big plus is knowledge of HTML and CSS, but besides the inspection you should be able to write selectors, this is a cornerstone of interacting with the web page, and, even though a lot of browser extensions which do this job for you are available, you should be able to write them on your own since this allows for more flexibility and is easier to maintain in the future. As to which selectors are better, XPath or CSS, I would say both are good and both have their place in the present, and knowing both is more valuable than just the sum of its parts.

Which language and framework should you know? It doesn’t really matter, as most of the principles are transferable. However, knowing ones that are most commonly used, or have been around for a long time can benefit you. I will expand on this more in the Learning on your own section and offer some suggestions, stay tuned.

From a role like this you can transition to other QA roles (those mentioned here and not), and also DevOps and Developer roles, with former being quite popular.

Agile tester

So, now comes the time for the flame wars discussion, as this role can be somewhat controversial. To be upfront, I am not trying to devalue anyone working in this role, or their contributions. In my opinion, this isn’t a role, but a way of performing your duties in agile software development settings. With incremental development such as Sprints in Scrum, the role of a tester (manual and automation) is expanded with additional responsibilities, e.g. release planning, testing metrics tracking, etc. The requirements mentioned for the roles above are applicable here, with the added requirement of being familiar with some form of the agile development process (most commonly Scrum).

Now, this is not the controversial part, as it can be beneficial in the long term, the controversial part is that in some settings the role of Agile tester is used as catch-all for all your testing and quality needs, in a nutshell if it seems like it can be tested, be agile and test it, if it is not clear who is responsible for it, be agile and take responsibility for it’s quality. Also manual and automation roles can be combined for this one. It is not uncommon to combine manual and automation roles, as they are overlapping, but mixing in some of the Scrum Master responsibilities, some of the developer responsibilities, and who knows what else can result in an unbearable environment which causes burnout and employee turnover.

I am not saying that you should avoid roles like this, but do your research upfront, look for employee reviews and avoid getting drowned in work if possible. There is a lot to learn in a role like this, and you can use it to skip over some steps to becoming a Scrum Master or Project Manager, but be careful about it.

Learning on your own

Is it possible? Yes. Is everything available? Yes. Is it a long and hard process? Depends on you, really.

The biggest question when it comes to any software related field is Where do I start? and since we all learn differently, there isn’t a universal answer to this one. That part I will leave to you, but I will cover the topics which you should research.

First topic should be the testing methodology. Here you should learn how to analyse something and think of a way to test it. It will benefit you to know some terminology, so going through some document, or even an article, can go a long way. If you are unsure where to apply that knowledge, take some hypotheticals that are often asked, like How would you test a pen? and run with it. It might be a silly exercise for someone with experience in the field, but when you are getting started it can give you a boost. You might want to pick an app on your phone, or some website that you use on a regular basis and put everything that you do in a test context, e.g. When I select a photo and click publish, then I should be redirected to the new post.

On the technical side, you should start with HTML and learn all the basics, somewhere along the way, CSS will surely be introduced, as the 2 are inseparable. Your goal here is to be able to locate things and make changes from inside the browser DevTools, know what they are doing and how certain things affect the look of the page. Once you are proficient here you can go on to the websites you visit daily and see what your actions are affecting on the page and understand how it is all linked.

After you feel comfortable here, you can move on to network requests, and how they fit in with the page. Understand different types, response codes and how you can track them from inside the browser. In my opinion this is a good starting point for a Software tester with no experience, you will have enough knowledge to fit in and enough terminology to understand basic workflows. Once hired, you will learn company specific knowledge, such as products, terminology, process, etc.

On the other hand, if you are aiming for a Test automation role, you would need a lot more technical knowledge, so after the finishing the first part focus on learning a programming language and a testing framework that can be used with it. Programming basics are important, but you will see bigger improvement if you jump straight into test specific areas, my suggestion here is learning the syntax, conditionals, loops and similar simpler concepts, and after that start learning a test framework (e2e, browser automation are the common names).
When it comes to specific languages and frameworks, my suggestion would be either the long-time industry standard Selenium (most often written in Java, but other programming languages can also be used) or go for newer JavaScript frameworks such as Cypress.io and WebdriverIO. (There are many others, but these I can recommend, I haven’t had the chance to use any Python or C# tools, so that is the reason I am not going over them).

Selenium can be a little intimidating in the beginning, as it has been around for a long time, but it has been battle tested and battle proven. Choosing it gives you the biggest pool of potential employers and knowledge is easily transferable to other frameworks. The down side is that it is not as abstracted as some newer frameworks, this means that you need more work (more lines of code, really) to achieve the same thing, this can be mitigated with a good base library that you develop for your use.

I personally, would go with a JavaScript framework here, both Cypress and WDIO are well abstracted and have nice boilerplates to get you started quicker. Documentation is quite good and both are actively getting new features on a shorter release cycle than Selenium. Downside is that they are still breaking into the market, so the potential employer pool is quite smaller.

To improve your skills in test automation I would recommend testing some example projects that you can run on your local machine, or find some live projects that are open to testing. Make sure that you have consent, don’t go around messing with random websites.

Automation frameworks are quite versatile, but what you need to know to do with them is quite simple for a no experience employee. If you have a knowledge of a testing framework I would expect you to be able to turn a login test scenario into an automated test, this can show the basics of test automation, some simple assertions and error reporting. On the other hand, if you don’t have experience with testing frameworks, I would expect a good knowledge of programming, and some track record of building simpler projects from scratch.

Is a course/certificate/bootcamp worth it?

Good thing about learning on your own is that you are not committing long term, and you can do it at your own pace at no cost (or very little). What about paid resources? If you are determined to get into software QA, you might also consider paying for a course, certificate, or joining a bootcamp. They offer some guarantees that you will land a job or highly increase your chances at getting a job, but that is not a given, or might be a marketing ploy, so be aware. It also depends a lot on the quality they offer, so, again, check reviews, make sure that you are getting a good return on what you pay.

From what I’ve seen, courses are the most uncertain option, as there are plenty of them and they don’t really stand out on a CV, certificates and bootcamps are much more noticeable and carry more weight. Having a course listed on your CV means that you are committed to learning, but are no guarantee that you passed the course, or learned the right subject matter. With certificates, I get a clearer picture of what you possibly know and can apply in the work environment, but they are not a replacement or guarantee for posted requirements, so those have to be present for a certificate to make you stand out. In my opinion, if you have more than a year of experience in the field, certificates become almost irrelevant.

And now, bootcamps. These can be a double-edged sword, as they might really benefit you when it comes to learning the right skill set, but can also turn out to be an “interview passing school”, which can work to your detriment. Reviews, reviews, reviews. What you can look forward to is working in groups, getting to know the processes in a simulated environment and being able to apply what you learn. There are some excellent people I know who came from a bootcamp straight into the workforce, and have been going strong since. The advantage that they often speak about is being focused on actual subject at hand and making sure to cover all the basics and all the general knowledge. This can show when compared to fresh Computer Science graduates who don’t focus (most commonly) on the quality side of software (your mileage may vary, there is a lot of different programmes, so it may not be true for the area you are in).

Conclusion

Looking for a job isn’t always easy (especially in this post-COVID, yet still COVID environment), and looking for your first job ever or trying to switch after years of working in an entirely different field can be scary. I hope that this post can help you tick some of the requirements and help you land the job that you’re after, or at least help you get started. If you don’t see yourself in this field after reading this, but still want to join it, don’t worry, I might be wrong, I’m just the guy on the internet who spent a few bucks on a domain name.

This article wasn’t meant as a step-by-step guide, or as an all-inclusive look into the QA field. There is a lot of things that I didn’t cover that might be required for a starting level role, like record and replay automation tools, test generators, things that I consider as not important for someone who is just starting out. If you have any questions feel free to reach out.