Manual Testing Best Practices
This is the last lesson in the Manual Testing Fundamentals track, and it's deliberately not about a new technique. It's about the habits that separate a tester who happens to know the vocabulary from one who's actually good at the job. Every item below ties back to something covered earlier in this track — think of this as the checklist you should genuinely keep taped above your desk.
1. Think Like a User and Like an Attacker
Most bugs live in the gap between "what a normal user does" and "what's technically possible to do." A good tester deliberately occupies both roles:
| Mindset | What it catches in RecipeBox |
|---|---|
| As a normal user | Add a recipe, search for it, edit it, delete it — does the everyday, happy-path flow actually feel right? |
| As a careless/confused user | Double-tap "Save" quickly, back out mid-upload, rotate the phone while typing ingredients — does the app survive being used imperfectly? |
| As someone probing for weaknesses | Paste a 50,000-character ingredient list, submit an empty title via a workaround, try a recipe search with special characters like % or ' — does input validation actually hold? |
2. Write Test Cases Before You Start Clicking
Ad-hoc exploratory clicking has real value (you learned that in Exploratory Testing), but it should follow a written test case pass, not replace it. Undocumented clicking finds bugs by luck; it can't prove coverage, can't be repeated identically by someone else, and quietly skips whatever the tester didn't happen to think of that day. Write the test cases first — even a simple table with Title / Steps / Expected Result — then explore on top of that foundation.
3. Always Write Reproducible Bug Reports
A bug a developer can't reproduce is a bug that doesn't get fixed. Every report needs clear numbered steps, the exact expected result, the exact actual result, environment details, and evidence (screenshot or screen recording) — the full structure from Writing a Good Bug Report. "The Add Recipe screen is broken" helps no one; "Steps: open Add Recipe, leave Title empty, fill every other field, tap Save → Expected: validation error blocks submit; Actual: recipe saves with a blank title and appears in the list" gets fixed the same day.
4. Don't Skip Regression Because a Change "Looks Small"
"It's just a one-line fix" is one of the most dangerous sentences in software. A one-line change to how RecipeBox validates prepMinutes can silently break recipe saving, recipe editing, and search filtering if any of them share that validation code. Regression testing exists precisely because small changes have a habit of breaking things nobody thought were related — run at least a targeted regression pass around anything the change could plausibly touch, every time.
5. Keep a Personal "Bug Pattern" Notebook
Experienced testers develop instincts, and instincts come from noticing patterns. Keep a running, personal list of the kinds of things that tend to break — not specific bugs, but categories. A few entries a RecipeBox tester might accumulate over time:
- Numeric fields (like prepMinutes) almost always have a boundary bug the first time they're built — always test 0, negative, and empty.
- Anything involving a photo upload tends to break on slow/interrupted network — always test with airplane mode toggled mid-upload.
- Screens that share a form component (Add Recipe and Edit Recipe both use the same form) often diverge in validation after one gets updated and the other doesn't.
- Search features are the most common place "it works for the exact match but not a partial or case-different match" bugs hide.
This notebook makes you faster every single project — you stop rediscovering the same categories of bug from scratch and start testing for them on day one.
6. Communicate Clearly With Developers
Testing isn't adversarial. A tester's job is to help ship good software, not to "win" against developers. That means:
| Do | Instead of |
|---|---|
| Report the bug with facts: steps, expected, actual | Reporting with judgment: "this is broken and sloppy" |
| Use the agreed severity and priority so developers know what's urgent | Marking everything "Critical" so nothing gets triaged properly |
| Ask questions when a requirement is genuinely ambiguous | Silently guessing and testing against your own assumption |
| Retest promptly once a fix lands and close the loop | Letting fixed bugs sit unverified in the tracker |
Putting It All Together: The RecipeBox Testing Story
Across this track you tested RecipeBox from every angle: understood what testing is and why it exists; learned where it fits in the SDLC/STLC; designed test cases with equivalence partitioning, boundary value analysis, decision tables, and state transitions; ran smoke, sanity, regression, and exploratory passes; tracked bugs through their full life cycle with the right severity and priority; wrote bug reports developers could act on immediately; and finally, planned and proved coverage of the whole effort with test plans, UAT, and an RTM. That's the complete, realistic loop a professional manual tester runs on every release — not 22 disconnected facts, but one repeatable process.