Not a loyalty test — a scheduling one. Scripted proves the behaviour you already know to check; exploratory finds what nobody specified. Here's which to reach for, when, and how to blend them in one cycle.
Not rivals fighting over the same budget — different jobs. Automation guards what you already know; manual testing judges what you don't. Draw the line wrong and you get a brittle suite and the important bugs still escaping.
Retesting confirms a fix works; regression checks the fix didn't break anything else. Plan them as one task and the 'we fixed it' build ships a brand-new bug. Here's the split, and how they combine after a fix.
Smoke asks 'is this build worth testing?'; sanity asks 'did this change work?' Both are quick gut-checks at different moments. Use them as gates before the real testing — and stop wasting a full pass on a dead build.
The three 'box' terms are interview trivia until you use them right: they describe how much of the code you can see when designing a test, which decides what you'll catch. Most functional QA is quietly grey-box — here's why.
Test cases that get read are short, scannable, and written for the person who has to act on them. Here is the format I use.
A ten-minute accessibility pass any QA can run before release — keyboard, focus, contrast, and the obvious screen-reader checks.
What separates a portfolio project that gets you an interview from one that screams tutorial-follower.
Tab through the page. That single habit catches more accessibility bugs than most automated scans.
A short, device-real smoke pass: permissions, offline, rotation, interruptions, and the update path.
A bug report exists to get the bug fixed. Specific title, minimal repro steps, explicit expected-vs-actual, evidence, and environment — the format that prevents "can't reproduce".
Not yes or no — which coding and for what. Reading code and light scripting help every tester; automation is where the roles are. Coding extends testing, doesn't replace the judgement.
A charter-driven, time-boxed template for exploratory testing: 5 minutes to charter, 35 to test, 10 to debrief — and notes someone can read.
A 30-second readiness check before accepting a ticket into QA — testable criteria, defined edge cases, reachable build, known data — that replaces a day of back-and-forth.
Three different tools on a spectrum from prescribed to open: when to write a scripted case, a coverage scenario, or an exploratory charter.
The working log that isn't a bug report or a test case — coverage, open questions, un-reproducible anomalies, painful setup — that makes a tester faster and more credible.
A short, risk-first status format: lead with a one-line risk verdict, then what's at risk, key findings, light coverage numbers, and explicit asks — built to drive a decision.
Write an operating manual for the arriver, not a diary: current state, setup, known issues with status, gotchas, and pointers — so someone can take over without asking you.
Tool-list-as-skills, duties not achievements, no quantified impact, generic and untailored — and the reframe that fixes them: prove you're good at testing, don't describe the job.
Use STAR to keep a bug story focused on your judgement: brief Situation and Task, an Action with reasoning, and a Result with impact — and pick a bug that shows thinking, not luck.
An honest map of QA's branches — deepening manual, automation, SDET, lead, manager — each rewarding different strengths, none 'up' from the others. Choose by what you like doing.
Six months from your first if-statement to your first paid automation contract — if you focus. Here's the path I'd take if I were starting today.
A 100 Lighthouse accessibility score doesn't mean your site is accessible. The score is a smoke alarm — useful, but not a test. Here's what it actually measures, and what you still need to check manually.
What automation replaced was regression checks — running the same path repeatedly. What it didn't replace, and can't replace, is human intuition trying to break a product.