Topic 10 — Landing the QA job

Goal: Present your skills to land an entry-level manual QA role.

Lesson 10.1 — Why QA is the door that opens

A year ago, Nadia Haddad was standing behind a pharmacy counter, comparing a prescription label against a doctor's order for the fortieth time that shift. No computer science degree. No "tech background." She'd never written a line of code. Today she's the newest manual tester at FreshCart, the food-delivery startup, filing bug reports against the checkout flow. The distance between those two jobs is smaller than it looks.

Manual QA is one of the most accessible entry points into tech. You don't need to code to start. The work rewards traits career-changers tend to arrive with already: attention to detail, patience, methodical thinking, and clear communication. And it drops you straight onto a real product team, sitting beside developers, designers, and a product manager.

That last part is the quiet advantage. Once you're inside, you can see how the whole machine works.

Manual QA is rarely the ceiling. It's the doorway — and from inside, the next room is always visible.

Marcus Bell, the lead QA engineer who mentors Nadia, started exactly here eleven years ago. He's watched testers on his teams move into test automation, into product management, into engineering. "Nobody starts in QA and gets stuck in QA unless they want to," he told her in week one. The job is a launchpad. Your first task is just to get on the pad.

Lesson 10.2 — Your old job was QA the whole time

In her first interview prep, Nadia kept apologizing for her resume. "Eight years in a pharmacy. I don't have any of the right experience." Marcus, reviewing it later, stopped her cold: "You verified that the right drug, the right dose, went to the right patient, every single time, with a documented procedure. What do you think testing is?"

That's the reframe. Any time you double-checked work, caught errors, followed a careful procedure, or documented an issue clearly, you were doing QA thinking. The vocabulary is new. The instinct is not.

Look at what different backgrounds already carry in:

• A pharmacy technician cross-checks one record against another and flags the mismatch before it reaches a person — that's comparing expected vs. actual and writing it up.
• An accountant reconciling the books is hunting for the one figure that doesn't tie out — that's a defect found by methodical comparison.
• A teacher writing instructions a ten-year-old can follow without a single question is writing reproducible steps — the core of a good bug report.
• A customer-service rep who heard the same complaint fifty times understands users and edge cases better than most engineers.

Nadia's "allergic to it probably works" reflex — the one that made her a careful pharmacy tech — is the exact reflex FreshCart is hiring for. Her job in the interview is to translate the experience she does have into the language of testing, not to invent experience she doesn't have.

Lesson 10.3 — A resume that signals QA before they finish reading

Tom Reyes, FreshCart's product manager, screens early resumes when QA hiring opens up. He spends about fifteen seconds on each one. He's scanning, not reading.

So Nadia made sure the first words his eyes hit were the QA vocabulary employers scan for: test cases, test plans, bug reporting, functional testing, regression testing, exploratory testing, Jira. Those terms tell a screener "this person speaks the job" before they reach a single date.

Then she reframed her past around accuracy and process. Not "worked at a pharmacy" but "Maintained 100% verification accuracy across 200+ daily prescriptions; documented and escalated dispensing discrepancies using a standardized log." Same eight years. Now they read as QA.

One more rule, and it matters more in QA than almost anywhere: keep it clean and keep it to one page. A typo on a QA resume is fatal in a way it isn't for other roles.

Your resume is your first test artifact. A QA candidate who ships a typo has just demonstrated, on the most important document they control, that they miss things.

Proofread it. Then have someone else proofread it. Then read it backwards, word by word, the way you'd check anything you couldn't afford to get wrong. That habit is the job.

Lesson 10.4 — Build proof you can do the job now

The wall every career-changer hits: no experience, so no job; no job, so no experience. Nadia got through it by refusing to argue she could do the work and instead showing she already had.

She built a mini-portfolio. The recipe is simple and anyone can do it this weekend:

1. Pick a popular real app. Nadia used a well-known food-delivery app, since it was close to FreshCart's world.
2. Find real bugs. She tested it like she meant it and found a promo code that applied twice, and a delivery-tracking screen that froze on a dropped connection.
3. Write professional bug reports for them — title, steps to reproduce, expected vs. actual, severity, evidence — exactly the format from Topic 6.
4. Add a sample test plan and a set of test cases for one feature, like checkout.

That folder did more than a paragraph of promises ever could. When Tom read it, he didn't have to imagine whether Nadia could test. He was holding the answer.

A portfolio beats "no experience" because it shows the work itself instead of just claiming it.

There's also the optional ISTQB Foundation Level (CTFL) — the widely recognized entry QA certification. The exam is 40 multiple-choice questions in 60 minutes, you pass at 65% (26 of 40 correct), and it costs roughly $200–$230 to sit in the US. It's not required, and a portfolio usually impresses a hiring manager more, but it signals seriousness, drills the standard vocabulary into you, and a few job ads ask for it. Marcus's take: do the portfolio first; add the cert if you have the time and money and want the extra signal.

Lesson 10.5 — The interview: think out loud

Nadia's interview loop had three flavors of question, and Marcus had warned her about each.

"How would you test X?" This is the signature QA interview question. Test a login page. Test a pen. Test a vending machine. Test a coffee machine. The object barely matters — they're watching how you think. The wrong move is rattling off random clicks. The right move is to structure it out loud, walking the categories you've spent this whole course learning:

• Happy path — does the normal case work? (Correct password logs in.)
• Edge cases — empty fields, very long inputs, the boundary values.
• Negative cases — wrong password, SQL in the username box, what shouldn't work.
• Usability — is the error message clear? Is the flow obvious?
• Compatibility / conditions — different browsers, mobile vs. desktop, slow network.

That's not a memorized list. It's the test-design thinking from Topics 4–7, said aloud. When Nadia got "how would you test the FreshCart promo-code field?", she narrated those buckets and the room relaxed. She sounded like a tester.

Knowledge questions come next, and they're definitions you now own: severity vs. priority. Regression vs. re-testing. The types of testing. What makes a good bug report. Answer cleanly and you've shown you know the field's language.

Behavioral questions are the third flavor: "Tell me about a time you found a critical error." "How would you handle a developer who says your bug isn't real?" Here Nadia thought of Priya Nair, the senior developer who builds FreshCart's checkout. The answer is never to win a fight. The goal is to stay factual and blameless and let the evidence carry it: clear reproduction steps, expected vs. actual, a screenshot or a log. "I'd walk them through the exact steps and show what I saw. Usually we find we were testing different builds." That answer says partner, not adversary, and that is what gets hired.

Worked example — Nadia's two weeks to an offer

FreshCart posts an entry-level manual QA role. Nadia has zero professional tech experience and decides to attack the job hunt with QA discipline.

Week one — the artifacts. She rewrites her resume to lead with test cases, bug reporting, regression, exploratory testing, Jira, and reframes her pharmacy years as "100% verification accuracy across 200+ daily prescriptions, standardized discrepancy logging." One page. Proofread three times, including backwards. Then she builds the portfolio: she tests a real food-delivery app, finds the double-applying promo code, writes two clean bug reports, and drafts a five-case test plan for checkout.

Week two — the interview. Tom Reyes asks, "How would you test FreshCart's promo-code field?" Nadia doesn't list clicks; she narrates the buckets — happy path, edge cases, negative cases, usability, conditions — and Marcus, in the room, catches Tom's small nod. Then the behavioral one: "A developer says your bug isn't real." Nadia: "I'd send the exact reproduction steps with a screenshot and the build number, and ask them to walk through it with me. It's usually an environment difference, not a disagreement."

She gets a callback the next morning — from the same person who apologized for her resume a year earlier. Different vocabulary, same careful mind. And the search itself ran like a test cycle: she tracked every application, noted which framing drew responses, and refined instead of spraying. That persistence — treating the hunt the way she'd treat a regression run — is the last skill the role asks for, and she already had it.