--- title: "05 — Manual Testing — Test Cases, Planning, and V&V" uid: manual-testing tags: ["roadmap:qa", "manual-testing", "test-cases", "verification", "compatibility", "test-plan", "validation"] excerpt: "Manual testing's real discipline is writing down, in advance, exactly what you'll check and what counts as pass — and that written-down inventory is what makes automation possible later." date: 2026-08-13T03:27:49+0000 source: https://www.aveshina.my.id/en/blog/manual-testing --- "Clicking around before release" was my manual-testing model, and it confused the visible activity with the discipline underneath. The split that fixed it: **manual testing the *activity* (a human executing checks) is the visible part; the discipline underneath is writing down, in advance, exactly what we'll check and what counts as pass** [1]. That written-down inventory — test cases, scenarios, the plan that contains them — is what makes everything else possible, including the automation later. You can't automate what was never specified. The framing that landed is that "manual" doesn't mean "unstructured." The most disciplined QA work I've seen was manual: every case written, every step numbered, every expected result stated before execution, every result logged with a traceable ID. The informality people associate with manual testing — ad-hoc clicking, "it feels broken" — is the *absence* of manual testing discipline, not its essence. The roadmap is explicit that manual testing's purpose is to identify bugs, issues, and defects, and that it's the most primitive technique — primitive as in foundational, not as in unsophisticated [1]. ## Test case versus test scenario The first distinction I had to nail down was **test case** versus **test scenario** [2]. They sound interchangeable and they're not. - A **test scenario** is a high-level situation — "a returning user logs in." It's one sentence, business-language, the kind of thing a stakeholder would say. - A **test case** is the concrete, repeatable instantiation — "given a registered user with email X and password Y, when they submit the login form, then they should be redirected to /dashboard and a session cookie named sid should be set with an expiry of 24 hours." It has explicit inputs, explicit steps, and an explicit expected result. One scenario fans out into many cases. "A returning user logs in" spawns cases for valid credentials, invalid password, unregistered email, locked account, expired session, SQL injection in the email field, and so on. The scenario is the *what*; the cases are the *how, precisely*. ```figure ``` The non-negotiable rule I took from this: **a test case without an expected result isn't a test — it's an observation.** If I can't state what "pass" looks like before I run it, I'm exploring, not testing, and exploring (covered in my next notes) is a different and legitimate activity with different rules. ## Verification versus Validation The next foundational pair is **Verification and Validation (V&V)**, and the roadmap phrases the distinction perfectly [3]: - **Verification** asks "Are we building the product *right*?" — does the software match its specified design and requirements? - **Validation** asks "Are we building the *right* product?" — does the software meet the actual needs of the user? These are different questions, and a project can pass one while failing the other. A perfectly specified, beautifully built system that solves the wrong problem *verifies* but doesn't *validate*. Conversely, a hacky prototype that delights users but violates its own spec *validates* but doesn't *verify*. The V-Model from my SDLC notes is essentially a verification framework — each test phase verifies a corresponding dev phase. Validation is what UAT (User Acceptance Testing) is for, and it's why UAT is performed by the actual end user, not the developer. The habit I internalized: at every review, ask both questions. "Does this match the spec?" (verification) and "Is the spec even right?" (validation). Teams that only verify ship beautifully built wrong things. ## The test plan: the container Above the test case sits the **test plan** — the document that describes the test strategy, objectives, schedule, estimation, deliverables, and resources for a testing effort [4]. It's the container that holds the cases, and it answers the questions that no individual case can: - **Scope** — what's being tested, and explicitly what's *not*. - **Approach** — manual, automated, or both; which levels (unit, integration, system, UAT). - **Environment** — hardware, OS, browser, database versions, network conditions. - **Schedule and effort** — when, by whom, how long. - **Entry and exit criteria** — what must be true to start testing, and what must be true to stop and call it done. - **Risks and mitigations** — what could go wrong with the testing itself. The test plan is where the prioritization from my foundations notes becomes concrete. The plan commits, in writing, to where the finite testing budget will be spent — and by omission, where it won't. A plan that tries to test everything tests nothing well; a plan that names its priorities and its exclusions is honest and executable. ## Compatibility: the often-skipped dimension The roadmap's **Compatibility** node is easy to overlook and expensive when it bites [5]. Compatibility testing checks whether the software runs across the hardware, operating systems, browsers, network environments, and devices it claims to support. The same code that works perfectly on Chrome desktop can break on Safari mobile, on a slow 3G connection, on a screen reader, or on a two-year-old Android. The failure mode is treating compatibility as "does it work on my machine, plus maybe one other browser." Real compatibility testing is a matrix: - **Forward compatibility** — does it work on the *next* version of the platform? - **Backward compatibility** — does it work on the *previous* version users haven't upgraded from yet? The matrix grows fast, which is why compatibility is one of the first things handed to automation — but the *design* of what to put in the matrix (which browsers, which devices, which versions) is a manual judgment call that lives in the test plan. ## Manual testing's enduring role A point worth making explicitly: manual testing isn't a relic that automation replaces. The roadmap's framing — "the most primitive technique of all testing types" — means foundational, not obsolete [1]. Automation is brilliant at *regression* — re-running known cases cheaply. Manual testing is irreplaceable at: - **Exploratory testing** — unscripted investigation that finds the cases nobody thought to write down. - **Usability** — whether the software *feels* right, which no assertion can capture. - **Visual verification** — does the rendered page actually look correct, not just does the DOM contain the expected elements. - **First-pass validation** — a human confirming a new feature works end-to-end before it earns the investment of automation. The relationship is complementary. Manual testing *discovers* the cases; automation *locks in* the ones worth re-running. A team that only automates automates the cases a human once found manually — and stops finding new ones. ## How I use this The practical payoff is a discipline I apply before any testing effort: - **Write the scenario first**, in business language, one sentence. If I can't, I don't understand the feature well enough to test it. - **Fan out into cases**, each with explicit inputs and an explicit expected result. A case without an expected result gets a question mark, not a pass. - **Check both V&V questions** at review — does it match the spec, and is the spec right? - **Put it in a plan** that names scope, environment, priorities, and *exclusions*. The exclusions are the most honest part. - **Build the compatibility matrix deliberately**, not by accident — decide which browsers/devices matter and write them down. The deeper habit is treating the test case inventory as the spec's executable shadow. Every case is a small bet that "this aspect matters"; the collection of those bets is the real definition of quality for the project. Manual testing is how that inventory is discovered and validated; the discipline of writing it down is what separates testing from hoping. ## References [1] Guru99, "Manual testing tutorial: what is, types, concepts," 2023. [Online]. Available: [https://www.guru99.com/manual-testing.html](https://www.guru99.com/manual-testing.html) [2] Guru99, "Test case vs test scenario — difference between them," 2023. [Online]. Available: [https://www.guru99.com/test-case-vs-test-scenario.html](https://www.guru99.com/test-case-vs-test-scenario.html) [3] Guru99, "Differences between verification and validation," 2023. [Online]. Available: [https://www.guru99.com/verification-v-s-validation-in-a-software-testing.html](https://www.guru99.com/verification-v-s-validation-in-a-software-testing.html) [4] Guru99, "Test plan: what is, how to create (with example)," 2023. [Online]. Available: [https://www.guru99.com/test-planning.html](https://www.guru99.com/test-planning.html) [5] Guru99, "What is compatibility testing? Forward & backward example," 2023. [Online]. Available: [https://www.guru99.com/compatibility-testing.html](https://www.guru99.com/compatibility-testing.html) ```quiz Q: The difference between a test scenario and a test case is… - nothing; they are synonyms - a scenario is a high-level situation; a case is the concrete instantiation with explicit inputs and expected results - a scenario is automated; a case is manual correct: 1 explain: One scenario ('a returning user logs in') fans out into many cases (valid creds, wrong password, unregistered email...). Each case has explicit inputs, steps, and an expected result. Q: A test case without an expected result is… - still a valid test, just a soft one - not a test — it's an observation, because there's no way to determine pass or fail correct: 1 explain: If you can't state what 'pass' looks like before running, you're exploring, not testing. Exploratory testing is legitimate but operates under different rules — it's not the same activity as a defined test case. Q: Verification asks 'Are we building the product right?'. Validation asks… - 'Are we building it fast enough?' - 'Are we building the right product?' - 'Are we using the right programming language?' correct: 1 explain: Verification checks the software matches its spec. Validation checks the spec matches user needs. A perfectly built wrong thing verifies but doesn't validate — which is why UAT, performed by real users, exists. Q: The most honest part of a test plan is usually… - the schedule - the exclusions — what the team explicitly won't test - the cover page correct: 1 explain: Naming what's out of scope forces the team to acknowledge the finite budget. A plan that tries to test everything tests nothing well; a plan that names its priorities and exclusions is executable. Q: Manual testing remains irreplaceable primarily for… - regression — re-running known cases cheaply - exploratory testing, usability, visual verification, and first-pass validation correct: 1 explain: Automation locks in regression for cases already discovered. Manual testing discovers the cases, judges usability and visual correctness, and validates new features before they earn automation. The two are complementary, not competitive. ```