Have you ever think about steps in the testing journey? Manual tester, QA, QA Engineer, Test Developer, SDET, TestOps? There are many ways you can develop in. But today, I want to stick with one - QA Engineer.

What does exactly this person do? What are the responsibilities and requirements? What should he know to work efficiently on daily basis?

I've summed up areas and described basing on daily tasks.

What does a QA Engineer do?

QA Engineer means Quality Assurance Engineer is a specialist whose activities are aimed to improve the software development process and product quality using engineering knowledge. Manual tests aren't optimal in most cases. QA engineers automate the most common cases, which saves us time and money.


  • write, design, and execute automated tests,
  • maximize test coverage,
  • determine the priority for test scenarios,
  • create execution plans for these scenarios,
  • write documentation for automated processes,
  • build automation frameworks,
  • set up continuous integration

And to reach the QA Engineer job, you need to know various things. I've categorized and described them.


You'll be obligated to write, design, and execute automated tests. It means you have to know how to do it. Writing automation tests isn't something very different than you're doing manually. I mean, to write this one, you have to perform these steps manually. So you have to take exactly the same steps as a user, and write this as a script. Experience with manual testing will let you write these scripts better.

From time to time, you'll also decide what's important, and what's not. What should be tested next, and how to maximize test coverage. Experience and knowledge about methodologies will help you with these decisions.

The priority of scenarios? Another important topic. Creating complex test solutions, most sure you'll face a problem with them. What should we automate first and why? What should we run first? These are hard questions, but important. We should always focus on more important parts of the application. Because we don't want to show the user some unexpected behaviors, bugs, or unavailability of the website. They'll lose trust in our product, which we can't afford.

Programming language

Writing tests, creating test frameworks and architecture is the same as with applications. To do this, you need to know a programming language.

Some of the wanna-be test developers, decide to learn frameworks first. Without the proper programming knowledge, they're trying to write tests. Probably this gonna work, but this solution won't be maintainable so much. While growing, they will encourage more and more problems, because basics were created wrong. Fix these mistakes lately, will cost much more time and afford than proper planning.

But language knowledge isn't in my opinion enough. You should also be familiar with the concepts of programming. KISS, YAGNI, DRY, SOLID - right now, they could sound for you like a buzz word, but believe me - you'll use them daily. Knowing them will give you the opportunity of creating more maintainable and better solutions.

Sometimes you'll also need to pass framework methods. Instead of using a page.click() you'll need to perform language native one. Sometimes, you'll need an API call that your test framework doesn't wrap up. You'll face many cases, where knowledge of the language is important.


  • JavaScript/TypeScript,
  • Java,
  • C#,
  • Python

Test tools

To write a test we're using test frameworks. These are tools set, out of the box, which gives you an easy way to control the browser. It means, writes a user like a scenario end's with a few methods. We don't have to reinvent a wheel, write from scratch integration with browser, etc.

Tooling is important, but concepts are more. While you know one test framework, you can easily switch to another. Most of them are very similar, it's like with a programming language, while you know the concepts and knows how to program, a language is literally a tool.

Example test frameworks:

  • Playwright,
  • Cypress,
  • Selenium


One of the bigger challenges is to set up pipelines. Nowadays, we're using Continuous Integration practice. Design and build a whole process is a very valuable skill.

You need to understand how deployment works, where you can run tests, how to do this?

To reach this, be familiar with topics like:

  • Docker,
  • CI/CD - Gitlab, Jenkins,
  • Cloud - AWS, Azure

There's a role called TestOps which is a connection between operations and testing, but I think mature QA Engineers should know the basics about processes, to be able to set up them from scratch.


QA Engineer role requires knowledge of many different areas. All of them affect the final solution, which with this knowledge will be better.

Knowledge of these areas also allows you to develop in various roles. Dive into processes? You can go into the TestOps position. Development? Then pick SDET.

Have a nice day! 🥳