Understand manual vs. automation QA and the common titles and terms.
Goal: Understand manual vs. automation QA and the common titles and terms.
It's Nadia's first week at FreshCart, the food-delivery startup, and Marcus — the lead QA engineer who's mentoring her — slides a phone across the desk. "Order a bag of oranges, apply the promo code WELCOME10, and tell me what the total does." So she does. She taps through the cart, types the code, watches the price drop, and notices the delivery fee didn't update. She writes down exactly what she saw.
What Nadia just did has a name: manual testing. A person uses the product directly — clicking, typing, looking — and applies human judgment to decide whether it behaves correctly. It needs no coding. Eight years as a pharmacy technician taught her to check a label twice before trusting it, and that instinct is the whole job here. This is the accessible entry point into QA, and it's where this course lives.
Down the row, Dev — the automation engineer — is doing something that looks nothing like tapping a phone. He's writing code that opens FreshCart, adds an item, applies a promo, and confirms the total, all by itself, in two seconds, a hundred times in a row. That's automation testing: scripts that run checks automatically and repeatedly. It's fast and tireless, but it requires programming.
So which is "real" QA? Both. They do different jobs, and the next lesson is about why a good team refuses to choose.
FreshCart pushes a code change almost every day. Before each one goes live, Dev's automation suite re-checks the same predictable paths — log in, add to cart, pay, track the order — in minutes. A human doing that by hand every single day would go numb and miss things. Machines are perfect for repetitive, stable, predictable checks that have to run on every change.
But the morning the team shipped the new live-map tracking, automation had nothing to say about it. Nobody had written a script for a feature that didn't exist yet. So Nadia opened it on a real phone, ordered a real sandwich, and watched the little courier icon — which froze on the map for thirty seconds, then teleported four blocks. No script would have flagged that. It took a curious human noticing that feels wrong.
Automation tells you the known things still work. A human finds the things nobody thought to check yet.
That's the division of labor on a healthy team. Automation owns the repetitive, predictable, stable checks. Humans own exploration, judgment, usability, and anything new. Marcus puts it to Nadia plainly: "Dev and I aren't competing. He frees me from the boring re-checks so I have time to actually think." They're partners, and the best testers respect both sides.
In her second week Nadia hears three words used almost interchangeably — QA, QC, testing — and quietly worries she's missing a distinction everyone else knows. There is one, and it's worth holding lightly.
Quality Assurance (QA) is the broad, process-wide effort to build quality in and prevent defects before they happen — good practices, clear requirements, reviews, standards. It's about the whole way the team works.
Quality Control (QC) is narrower: checking the finished product for defects that slipped through. It's inspection after the fact.
Testing is the hands-on activity itself — actually running the checks to find bugs. Testing is one of the main things you do inside QC, which lives inside the bigger world of QA.
Think of how a restaurant kitchen works. Writing the recipe so the dish comes out right every time is assurance. Tasting the plate before it leaves the pass is control. Lifting the spoon to your mouth is testing.
Here's the practical part. In job ads these lines blur constantly, and the titles QA Engineer, QA Tester, Test Engineer, and Software Tester usually mean the same role. Don't get hung up on which word a company chose. Read the responsibilities in the posting — that's where the real job is described.
A spelling mistake sits in the FreshCart logo on the homepage — it reads "FrshCart." Meanwhile, a crash hides in an admin-only tool that exports last month's invoices, used by one person in finance once a month. Nadia logs both. Then Marcus asks the question that separates juniors from pros: "Okay — for each one, how bad is it, and how urgent is it?" She assumes those are the same question. They aren't.
Severity is how bad the bug's technical impact is. The common ladder, worst to mildest:
Priority is how urgent the fix is — how soon it needs to happen. Teams usually label it High / P1, Medium / P2, Low / P3.
The trap is assuming they always match. They don't — they're independent axes, and the classic examples prove it:
| Bug | Severity | Priority | Why |
|---|---|---|---|
| Typo in the company logo on the homepage | Low (cosmetic) | High | Every visitor sees it; it's embarrassing for the brand |
| Crash in the rarely-used admin export | High (it crashes) | Low | Almost no one hits it; can wait |
Severity is how bad. Priority is how soon. A trivial typo can be top priority; a real crash can wait.
And who decides? On most teams Nadia, as QA, owns severity — she's the one judging technical impact. Tom, the product manager, owns priority, because urgency is a business call: the brand-embarrassing logo typo jumps the queue not because it's severe but because it's visible. Knowing this keeps you from arguing the wrong axis with the wrong person.
By the end of her first sprint, Nadia can sit in a standup and follow every word, because she's learned a handful of terms that come up constantly. You don't need to master them today — each gets a full topic later. You just need to recognize them.
Two terms deserve a closer look, because beginners get burned by them.
An environment is where you test. You almost never test on production — the live app real customers are using right now. You test on staging, a near-identical copy that mirrors production. That's how Priya, the developer who builds checkout, and Nadia can break things freely without charging a real customer for oranges they never ordered.
Staging is the rehearsal stage. Production is opening night. You never experiment on opening night.
A release or build is just the labeled version handed over — "test build 1.4.2 on staging" tells you both what and where. Once these words stop being noise, every QA conversation opens up.
Nadia finds a posting titled "QA Engineer" and, instead of panicking at the jargon, decodes it line by line.
"Perform manual testing of new features on staging before each release." She translates: hands-on checking, on the rehearsal copy, on each version handed to QA. That's exactly the work Marcus gave her in week one. She can do this.
"Log defects with clear severity and priority." File bugs and judge two separate things — how bad, and how urgent. She thinks of the logo typo: low severity, high priority. She understands the distinction the ad assumes.
"Run regression checks; collaborate with developers and product on triage." Re-test old features after changes, and sit with people like Priya and Tom to sort what gets fixed when. Partnership, not policing — she gets it.
"Familiarity with automation (Playwright) a plus." A plus, not a requirement. That's Dev's world. She doesn't have it yet, and the ad says she doesn't need it to start — it's the next door to open. She's not disqualified.
One posting that would have looked like a wall of intimidating terms two weeks ago now reads like a description of a job she could actually do. That decoding ability is the entire point of this topic.
Find one real "QA Engineer" or "Software Tester" job posting online. Go through the responsibilities and tag each line as manual work, automation work, or neither. Then circle any term from this topic that appears — severity, priority, regression, staging, build, SDET. Notice how much of it you can now read without flinching. That's the same first move Nadia made, and it's how you aim at roles that actually fit you instead of applying blind.
Preparing your quiz…