Topic 1 — What is QA?

Goal: Understand what quality assurance is and the value a QA engineer creates.

Lesson 1.1 — One job, said plainly

It's Nadia Haddad's first morning at FreshCart, a 40-person food-delivery startup, and she's terrified she's about to be asked to write code. For eight years she was a pharmacy technician, checking prescriptions and catching dosage errors before they reached a patient. She can't build an app, and she's wondering what she's doing in a room full of engineers.

Her manager, Marcus Bell, the lead QA engineer, sits down and says one sentence that unknots her whole stomach: "Your job is to make sure the app works for real people before we ship it to them."

That sentence is the whole role. A QA engineer's one core job is to find and report defects — bugs — before a release reaches users. Not write the main product code. Not manage the developers. Check that what was built actually works, and raise a clear flag when it doesn't.

Nadia relaxes, because she's done a version of this her entire career. Catching a wrong dose before it leaves the counter, double-checking, refusing to wave something through on "it probably works" — that is the QA instinct. The product is new; the mindset is hers already.

QA's product is not the app. QA's product is confidence — a defensible answer to the question "is this safe to release?"

Lesson 1.2 — The math that makes the job exist

In week two, Nadia asks Marcus the question every career-changer asks privately: why pay a whole person just to look for problems? Can't the developers catch their own mistakes?

Marcus pulls up a real example. A few months back, a checkout bug slipped past everyone: promo codes silently failed to apply, so customers were charged full price. It wasn't found in testing. It was found by users — hundreds of them, on a busy Friday night — who got charged wrong, flooded support, and demanded refunds. The team scrambled an emergency fix at 9pm, FreshCart refunded the difference, and some of those customers never ordered again.

That's the cost-of-late-bugs rule, and it's the economic reason QA exists. The same bug costs almost nothing if a tester finds it before release. Found after release, by thousands of users, it gets dramatically more expensive: emergency engineering time, refunds, lost sales while checkout is broken, and the slow damage of people deciding the app can't be trusted.

Where the bug is caught	What it costs FreshCart
In testing, before release	A bug report and an hour of a developer's time
In production, by users	Emergency fix + refunds + lost orders + reputation

Studies disagree on the exact multiplier, so be skeptical of anyone quoting a precise "100x." But the direction is not in doubt: the later a defect is caught, the more it costs. Nadia's salary is cheaper than one bad Friday night — that's the trade FreshCart is making, and she's the good side of it.

Lesson 1.3 — What QA can and can't promise

There's a trap Nadia almost falls into, and Marcus heads it off early. She tests the new "live order tracking" map for two solid days, finds nothing, and writes "no bugs — it's fine to ship." Marcus gently fixes the wording with her, teaching her the most important sentence in the whole field, the first of the ISTQB seven testing principles:

"Testing shows the presence of defects, not their absence."

Read it slowly, because it reshapes the job. Testing can prove a bug exists — you found it, you can reproduce it, here it is. Testing can never prove a bug doesn't exist. Finding nothing only means you found nothing where you looked, not that the software is flawless. Exhaustive testing — every possible input on every possible device — is impossible for any real app.

So a good QA engineer never promises "zero bugs." That's a promise no one can keep. What Nadia learns to deliver instead is reduced risk: she's tested the paths that matter most, the ones real customers hit hardest, and the remaining unknown risk is now small enough to release with eyes open. Her report becomes "I tested the main flows and these edge cases; here's what I found, here's what I didn't get to" — honest, and far more useful than a false "it's fine."

This is also why "it probably works" makes her itch. Probably is not a tested claim. It's a guess wearing a lab coat.

Lesson 1.4 — Priya is on the same team

Nadia files her first real bug on the checkout, and her hands are a little sweaty doing it. The code belongs to Priya Nair, a senior developer who built the payment flow and wrote its unit tests. Nadia is about to tell a seasoned engineer that her work is broken, and she braces for a fight.

There isn't one. Priya reads the report, replies "good catch — reproduced it, that's an edge case I missed," and ships a fix by lunch.

That exchange is the heart of QA–developer partnership. QA is not fault-finding, and a bug report is not an accusation. Building anything complex follows the same loop every time: build, check, fix, ship. The "check" step finding something is the loop working, not the developer failing. Priya wrote tests for the cases she could think of; Nadia's value is thinking of the cases Priya couldn't, because she comes at the app as a suspicious user instead of its author.

Good QA and good developers want the exact same thing: a product users can trust. They just attack it from opposite ends. When Nadia frames a bug as "here's what I saw, here are the exact steps, here's why it matters to a customer" instead of "you broke this," Priya stays a partner. Marcus's rule for her: report the behavior, never the person. A whole later topic covers writing bug reports that land this way.

Lesson 1.5 — A real day, and the mindset underneath it

So what does Nadia actually do between nine and five? Tom Reyes, FreshCart's product manager, has just written the spec for a new "schedule delivery for later" feature. Here's Nadia's week with it.

She reads the requirements — Tom's spec for how scheduled delivery should behave. She plans her tests — listing what could go wrong: What if someone picks a time in the past? A holiday? A slot that's already full? She executes the tests — walking the happy path (everything goes right) and the ugly edge cases (the weird inputs most people never try). She writes bug reports for what breaks, clear enough that Priya can reproduce each one. Then she re-tests fixes once they land, confirming the fix works and didn't break something nearby.

Notice what's not on that list: writing the feature's code. Nadia is checking and documenting, not building. Later she'll meet Dev Okafor, the automation engineer who maintains FreshCart's Playwright regression suite, and see where automated and API testing fit — but the core of manual QA is this loop of read, plan, test, report, re-test.

Underneath all of it runs one trait, the thing that actually makes someone good at this. Call it constructive curiosity. It's two instincts at once: the methodical inspector who checks every item like Nadia checked every prescription, plus a slightly mischievous user who grins and thinks "what happens if I do this?" — tapping "place order" twice, entering a promo code in ALL CAPS with a trailing space, putting the delivery address as a single emoji. She isn't breaking things to be destructive. She's breaking them on purpose, in private, so they can't break in front of a paying customer.

That instinct to double-check and to ask "what did they forget?" — Nadia walked in the door with all of it. The rest of this course just teaches it a new vocabulary.

Worked example — The promo code that lied

A new feature lands on Nadia's plate: a "$10 off your first order" promo. Tom's spec is one line — new customers get $10 off orders over $25. Watch the whole job run in miniature.

She reads the spec and senses the gaps a single sentence leaves. New customers — but who counts as "new"? Over $25 — so what happens at exactly $25?

She plans tests around those gaps and executes them. The happy path works: a new customer, a $30 cart, $10 comes off. Then she pushes on the edges. A $24 cart is rejected — correct. At exactly $25.00 the discount silently fails to apply, even though "over $25" should arguably include the threshold. Then the real find: she applies the code, removes an item to drop the cart under $25, and checks out — the $10 stays applied, so FreshCart sells a $20 order for $10.

She does not write "promo is broken." She writes a clear bug report: exact steps to reproduce, what she expected, what actually happened, and why it matters — this lets any user buy under the minimum at a discount, straight margin loss on every order. Priya reproduces it in minutes, fixes the cart-revalidation logic, and Nadia re-tests: the discount now drops correctly when the cart falls under $25, and Tom confirms the $25.00 boundary as "included."

A bug that would have leaked real money on every abused order, caught for the price of one careful afternoon. That afternoon is the job.