You've probably seen the job ads: "QA Automation Engineer — $70k–$120k, remote, Selenium/Playwright." You open a tutorial, write your first driver.get("https://example.com"), and feel like you're on your way. Three months later, you're still copy-pasting code from Stack Overflow, your tests break every other day, and interviews end with "we'll call you." The problem isn't your effort — it's the myths you've absorbed about what automation actually is. Let's bust the five most expensive ones.
Myth 1: "Automation is just writing scripts that click buttons"
What people believe: A QA Automation Engineer records user actions, wraps them in a loop, and runs them. The job is syntax. More on the topic: “First Job Without Experience”.
What's actually true: Automation is software engineering applied to testing. You're building a product — a test framework — that other people will maintain, extend, and trust. That means version control, code reviews, design patterns, and CI/CD pipelines. The clicking part is maybe 10% of the work.
Take a concrete task: verify that a login form rejects invalid credentials. A beginner writes:
from selenium import webdriver
from selenium.webdriver.common.by import By
driver = webdriver.Chrome()
driver.get("https://app.example.com/login")
driver.find_element(By.ID, "username").send_keys("user")
driver.find_element(By.ID, "password").send_keys("wrong")
driver.find_element(By.ID, "submit").click()
assert "Invalid" in driver.page_source
``` More on the topic: “[Open Source Contribution](/en/blog/open-source-contribution-the-mistakes-beginners-make-the-pr-that-actually-gets-merged-and-the-licences-everyone-misreads)”.
This passes once. Then the team changes the button ID, adds a loading spinner, or runs the test in parallel with three others — and it fails. A practitioner writes the same test with a Page Object, explicit waits, and a test data factory:
```python
class LoginPage:
def __init__(self, driver):
self.driver = driver
self.username = (By.ID, "username")
self.password = (By.ID, "password")
self.submit = (By.CSS_SELECTOR, "button[type='submit']")
def login(self, user, pwd):
self.driver.find_element(*self.username).send_keys(user)
self.driver.find_element(*self.password).send_keys(pwd)
self.driver.find_element(*self.submit).click()
Now the selector lives in one place. When the UI changes, you fix one line, not fifty tests. That's the difference between a script and a framework.
Myth 2: "Selenium is outdated; just use Playwright"
What people believe: Playwright is newer, so Selenium is dead. Learning Selenium is a waste of time.
What's actually true: Both are tools, and the choice depends on context. Selenium still dominates enterprise environments with legacy browsers, grid infrastructure, and large existing suites. Playwright wins on speed, auto-waiting, and built-in parallelism — but it only supports Chromium, Firefox, and WebKit. If your company tests on IE11 (yes, some still do), Playwright won't help. More on the topic: “AI Tester (AI Auto-Tests)”.
A hiring manager doesn't care which tool you memorized. They care whether you understand why a test is flaky and how to fix it. That skill transfers across tools. Learning Selenium first teaches you explicit waits, the DOM, and cross-browser quirks; Playwright then feels like a relief, not a mystery.
Myth 3: "API tests are optional once you have UI tests"
What people believe: If the UI works, the backend works. API tests are extra credit. More on the topic: “Go for Backend (gRPC)”.
What's actually true: UI tests are slow, brittle, and expensive. A single end-to-end UI test can take 30–60 seconds; an API test for the same logic takes milliseconds. More importantly, UI tests can't isolate where a failure comes from — is the bug in the frontend, the API, or the database?
Consider a checkout flow. A UI test clicks through five pages, waits for spinners, and asserts the order confirmation. If it fails, you debug for an hour. An API test hits POST /orders with a payload and checks the response in 200ms. When the UI test fails later, you already know the API is fine — the bug is in the frontend.
The pyramid still holds: many unit tests, a solid layer of API tests, and a thin layer of UI tests for critical paths. Skipping API tests means you're paying for flakiness.
Myth 4: "CI/CD is someone else's job"
What people believe: You write tests; DevOps wires them into the pipeline. More on the topic: “DevOps & Cloud”.
What's actually true: A test that doesn't run on every commit is a test that rots. Automation engineers are expected to own the pipeline integration — at least the test stage. That means knowing how to run tests headlessly, parallelize them, and publish reports. More on the topic: “QA Engineer”.
Here's a minimal GitHub Actions workflow that runs Playwright tests on push:
name: Playwright Tests
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
Without this, your tests live on your laptop and die there. With it, every pull request gets a pass/fail signal — and you become the person who makes releases safer.
Myth 5: "Performance testing is a separate specialization"
What people believe: Load testing is for performance engineers with JMeter and a dedicated environment.
What's actually true: Basic performance testing is part of the automation engineer's toolkit. You don't need to model 10,000 concurrent users on day one, but you should know how to run a smoke load test with k6 or JMeter to catch regressions.
A simple k6 script:
import http from 'k6/http';
import { check } from 'k6';
export let options = { vus: 10, duration: '30s' };
export default function () {
let res = http.get('https://api.example.com/health');
check(res, { 'status is 200': (r) => r.status === 200 });
}
Run this after a deploy and you'll know if the API suddenly takes 2 seconds instead of 200ms. That's not deep performance engineering — it's basic hygiene, and it's increasingly expected from QA Automation Engineers.
Where people actually go wrong (and what it costs)
The myths above share a root cause: treating automation as a collection of tools rather than a system. The cost is measurable. A beginner who skips Page Objects spends roughly 30–40% of their time fixing broken selectors. One who ignores API tests waits minutes for feedback instead of seconds. One who never touches CI/CD ships code that works locally and fails in production.
The fix isn't another tutorial. It's deliberate practice on a realistic project — with code review. That's where self-study hits a wall: you can write a test, but you can't tell if it's good. You need someone to point out that your wait is implicit, your selector is fragile, or your test data leaks between runs.
Structured courses close that gap. A good one walks through building a framework from scratch — Page Object, test data factory, parallel execution, CI integration — and gives feedback on your decisions. The QA Automation Engineer course on asibiont.com does exactly that: text-based lessons adapted to your level, covering Selenium, Playwright, Cypress, API testing with REST Assured and Postman, Appium, CI/CD, and performance testing with k6 and JMeter. The final project is a full pipeline — not a toy script.
But the course is one path. Self-study works if you have discipline and a mentor; bootcamps work if you need deadlines. The trade-off is time versus feedback: self-study is cheap but slow to correct mistakes; courses cost money but compress the learning curve.
Who this path suits — and who it doesn't
Automation suits people who enjoy debugging, tolerate ambiguity, and think in systems. It does not suit those who want a purely creative role or hate reading logs. If you've ever spent an hour chasing a bug and felt satisfied when you found it, you'll likely thrive. If that sounds like torture, consider manual QA or product management instead.
The field is not going away. As AI generates more code, the need for reliable automated checks grows. But the bar is rising: knowing Selenium isn't enough; you need to design test strategies, integrate with pipelines, and interpret results. Start with one tool, one API test, one CI job — then expand. The myths above are the main reason beginners stall; avoid them, and you'll be ahead of most applicants. More on the topic: “Mobile Development”.
If you want a structured path that forces you to build a real framework and get feedback on it, the QA Automation Engineer course is a practical starting point — details and enrollment are on the course page. More on the topic: “CI/CD as an Art”.