05 — Manual Testing — Test Cases, Planning, and V&V

"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.

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

[2] Guru99, "Test case vs test scenario — difference between them," 2023. [Online]. Available: 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

[4] Guru99, "Test plan: what is, how to create (with example)," 2023. [Online]. Available: 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