IT-related professions continue to excite minds and attract new employees. One of the most honored positions is that of a Quality Assurance engineer, or a QA engineer. A QA engineer is responsible for testing software during its development and reducing the risk of errors and problems before the product is released.

But there is a misconception in the field. Some believe that you do not actually need technical skills or knowledge to be a QA engineer because you would just push buttons and write down what happens.

To find out more, we spoke with Alexander, QA engineer at Loovatech.

The article will be useful to junior or middle-grade QA engineers and anyone who is thinking about entering the profession.

Key skills

Different projects require different skills, so I cannot say for sure that you will become a star QA engineer after learning something in particular. But the following skills are always in demand:

1. Fluent and clear written language

A QA engineer should be able to clearly convey their thoughts in writing. The writing should be as precise and as clear as possible, and easy for others to understand. Inability to create concise and understandable text is incompatible with the profession. 

2. Working with the browser developer tools

All tabs in the developer panel, with an emphasis on the Network tab. I often see software people including developers who, even when they have access to a fully functioning UI and API with Swagger or other form of documentation, could not understand how to create a correct request to the server. The network tab is of great help here. There are also cases when you can use the console to send a request to a server and read its response. The tool is built into all modern browsers, so it would be a waste not to use it.

3. When working with  REST API, the client is not important, you can just use cURL

This basic skill will ensure that a QA engineer will be able not only to create defects based on documentation (QA), but will actually monitor the quality of the product (QC). With some experience in API testing and an insight into implementations, a QA engineer can point out potentially risky decisions on the developer's end. An engineer like that will also more likely be able to predict errors (Error Guessing).

4. SQL

In most cases a QA engineer will use SQL in the form of ready-made queries from a project wiki, or provided by a developer or a DBA. You need to understand what a database is and how everything works there, at least in some approximation. You would be able to predict errors based on constraints and field limits. You will also be able to perform tasks related to migrations or relocations and to collect statistics. However, this skill is probably compulsory at the initial stage. But in my work using SQL is a day-to-day skill which helps with problem localization.

5. Being a confident user of your OS, Linux/Windows/MacOS is not as important

But you should be able to set up your OS to be your work driver. Editing .hosts, creating a VPN connection, deploying a virtual machine or a Docker container if need be. Setting an environment variable, executing a line of code in bash or PowerShell script. you need to be able to figure out how to do that if need be.

List of books on the topic:

• How they test at Google. Authors: James Whittaker, Jason Arbon, Jeff Carolo.

• Software testing. Authors: Sam Kaner, Jack Faulk, Yeng Kek Nguyen.

• The art of program testing. By Glenford Myers, Tom Badgett, Corey Sandler

• A Practitioner's Guide to Software Test Design. Author: Lee Copeland.

• Lessons Learned in Software Testing. Authors: Cem Kaner, James Bach, Bret Pettichord.

• Agile Testing. Authors: Lisa Crispin, Janet Gregory.

6. Ability to localize and then document defects.

That’s the main skill. If you will learn and apply it, all team members will thank you:

• Learn and use markup for your documentation system

• Practice and refine your bug summary skills, really lean here into that concise writing

• When possible, attach the data that can be used to reproduce, i.e. as a text file, as a JSON, as a full cURL command, so that your colleagues would not have to recreate it from scratch.

• Test against documentation, not your hunch. Sometimes you will discover that what you have found is not a bug but actually a properly implemented feature. Ensure that it is actually a bug by checking the project wiki, and always add the expected result, basing it on and referencing the documentation. Do not force the developer to figure out what the proper output should be, it is a team effort after all.

What about languages?

If you have skills and passion for programming, this will always help in any project. But a good manual tester is sometimes more valuable than a person with programming skills.

If you want to learn a programming language for your QA role, study Python. Because of its large community, and the huge number of ready-made solutions. But even if you don’t can’t tell your Python from your Ruby, it is still necessary to understand the basics of programming:

1. Data types

2. Conditions

3. Cycles

4. Functions

5. Exception Handling

6. Object Oriented Programming

All of that can be studied outside the context of any particular language.

It is much more useful to familiarize yourself with HTML/CSS. This will help you feel a little more confident when you hear from colleagues about a hover, a debounce, some background, a toast or a modal. There are a large number of sources on the Internet where you can find this information.

Here’s some advice

• Do not be afraid to express your thoughts. It is rare to see QAs patiently trying to get their point across without giving up. In the hierarchy of IT companies, the QA position is considered to be lower than any other profession, so it is harder to communicate your vision of the problem. Sometimes that even leads to bugs in production. QAs often have their thoughts or concerns dismissed but we still need to keep voicing our doubts. It is important to be a person who asks uncomfortable or seemingly dumb questions.

• If you have to check something monotonously by hand, think about automation. If you cannot do it yourself, ask your manager for help and resources. Every time you start doing something, ask yourself whether it can be automated. 

• Learn to estimate your work properly. Overestimation will lead to people not believing you. You will find what to do if you finish your part early, trust me.

• Be meticulous. Every detail is important and has its own meaning. Always clarify if something does not match the description in the docs. Ask your colleagues if they can understand what you meant, and use their feedback.

• Abandon private messages and discuss issues in a public project. Everyone involved will be aware of what is happening, and perhaps somebody who is in the know will chime in unexpectedly.

• Join QA communities on Reddit, Discord, go to local meetups. Communities are a souce of tons of useful information. There you can ask for advice or share your own experience.