Learning Objectives
By the end of this lesson you will be able to:
- Compare the structure of a manual test case with a Gherkin scenario
- Identify what information a scenario keeps and what it deliberately drops
- Explain why a scenario is not just "a test case with different formatting"
Same Feature, Two Documents
Consider testing "apply a discount code at checkout."
Manual test case (typical structure):
| Step | Action | Expected Result |
|---|---|---|
| 1 | Add item to cart | Item appears in cart |
| 2 | Go to checkout | Checkout page loads |
| 3 | Enter code "SAVE10" | Field accepts input |
| 4 | Click "Apply" | Discount of 10% is shown |
Gherkin scenario for the same behavior:
Given a cart containing one item priced at $50
When the user applies the discount code "SAVE10"
Then the cart total reflects a 10% discount
What Changed
The manual test case is a procedure — a numbered sequence of UI clicks. It tells you exactly how to operate the interface, which is valuable when a human is executing it step by step, but it's tightly coupled to this specific UI. If the checkout flow gets redesigned, the steps need rewriting even if the underlying business rule hasn't changed.
The Gherkin scenario is a behavior description — it says nothing about clicking a button or which page loads. It says: given this state, when this business action happens, then this business outcome follows. The scenario survives a UI redesign untouched, because it was never coupled to the UI in the first place.
What Stayed the Same
Both documents ultimately verify the same thing: does the 10% discount apply correctly? Neither format is "more correct" than the other — they answer to different needs. The manual test case is a runbook for a human tester clicking through a browser. The scenario is a behavior contract that stays valid regardless of how the behavior gets executed (by hand today, by automation tomorrow).
The Trap to Avoid
A common beginner mistake is writing Gherkin scenarios that are secretly manual test cases in disguise — full of UI details like When the user clicks the blue "Apply" button in the top-right corner. That's a smell. If your When step describes pixels instead of business actions, you've written a checklist wearing a Gherkin costume.
Pro Tip: A good litmus test: could this scenario survive a full UI redesign without a single word changing? If yes, you wrote a real scenario. If no, you wrote a disguised manual test case.
Key Takeaways
- Manual test cases are UI-coupled procedures; Gherkin scenarios are UI-agnostic behavior descriptions
- Both verify the same underlying business logic, for different audiences and purposes
- A scenario should survive a UI redesign unchanged — if it can't, it's too implementation-specific
- Writing "click the blue button" in a
Whenstep is a sign you've written a disguised test case