A QA engineer (quality assurance engineer) uses engineering skills to improve the development process and the quality of the product. In practice that means mostly automating tests. The career has many branches: manual tester, QA, QA engineer, test developer, SDET, TestOps. This post covers one of them, QA engineer, and what I use in my daily work.
QA engineer vs tester vs SDET
The titles overlap, and companies use them differently. This is how I use them:
| Role | Main work | Writes code? |
|---|---|---|
| Manual tester | Runs test cases by hand, reports bugs, explores the product | Rarely |
| QA engineer | Plans testing, automates the most common cases, sets up test runs in the pipeline | Yes, test code |
| SDET (software development engineer in test) | Builds test frameworks and tooling like a developer would | Yes, a lot, close to a developer role |
| TestOps | Runs the infrastructure, pipelines and environments tests depend on | Scripts and configuration |
Check the job description and not the title. The same title can mean different things at two companies.
What does a QA engineer do?
Manual testing doesn’t scale in most projects, so QA engineers automate the most common cases. That saves time and money.
Typical responsibilities:
- write, design, and run automated tests
- maximize test coverage
- set priorities for test scenarios
- create execution plans for those scenarios
- document automated processes
- build automation frameworks
- set up continuous integration
To get there you need skills in four areas.
Testing methodology
Writing an automated test is the same job as testing manually, written as a script. To automate a scenario you first have to run it by hand and take the same steps as a user. Manual experience makes the scripts better.
You also decide what matters. What do we test next? How do we raise coverage? Knowing testing methodologies helps with those calls.
Priorities are the hardest part. What do we automate first, and why? What runs first? Focus on the most important parts of the application. If users hit unexpected behavior, bugs, or an unavailable website, they lose trust in the product.
Here is how I think about it, as a hypothetical example and not a story from a specific project. A shop has a login, a product search, a checkout and a “change avatar” page. If checkout breaks, the business loses revenue that day. If the avatar upload breaks, a few users are annoyed. So checkout and login get automated first, search second, avatar last or not at all. Ask of every candidate flow: what happens to the business if this breaks, and how often does it change? That question is the same one behind smoke, sanity and regression suites.
Programming language
Test frameworks and test architecture are built like any application, so you need a programming language.
Some aspiring test developers learn a framework first and try to write tests without proper programming knowledge. That works for a while. The code then turns hard to maintain, and problems pile up because the basics were wrong. Fixing that later costs far more time than planning it properly.
Language knowledge alone isn’t enough either. Learn the programming concepts: KISS, YAGNI, DRY, SOLID. They may sound like buzzwords now, but you’ll use them every day, and they lead to more maintainable solutions.
Sometimes you’ll also work around your framework. Instead of page.click() you’ll need plain language code, or an API call the framework doesn’t wrap. In those moments language knowledge decides how fast you get unstuck.
Languages commonly used for test automation:
- JavaScript/TypeScript
- Java
- C#
- Python
Test tools and frameworks
A test framework gives you a ready toolset to control the browser. A user scenario takes a few method calls, and you don’t have to build browser integration yourself.
Tools matter, concepts matter more. Once you know one framework you can switch to another quickly, because most are similar. It works like programming languages: if you know the concepts, the language is just a tool.
Popular test frameworks:
- Playwright
- Cypress
- Selenium
To write your first test, follow the Playwright tutorial. Once tests exist, make them survive UI changes with stable selectors.
CI/CD and processes
Setting up pipelines is one of the bigger challenges. Today we use continuous integration, and designing and building the whole process is a valuable skill.
You need to understand how deployment works, where tests can run, and how to run them there. Be familiar with:
- Docker
- CI/CD (GitHub Actions, GitLab, Jenkins)
- Cloud (AWS, Azure)
TestOps is a role between operations and testing. Even so, I think a mature QA engineer should know the basics of these processes well enough to set them up from scratch.
Which skills lead to which QA career path
These areas all feed into the final solution, and knowing them lets you move into other roles. Like processes? Look at TestOps. Prefer development? Pick SDET.
If you are thinking about interviews for these roles, read why test engineers fail interviews. If you are just starting, first steps in test automation answers the first questions. For the structure behind a framework, see six things to consider when designing a test architecture.