The UI-Click Trap

Learning Objectives

By the end of this lesson you will be able to:

Recognize a scenario written as a UI-click script
Explain why click-scripts are brittle, noisy, and unhelpful to business readers
Compare a click-script scenario against its business-rule intent

The Trap, Illustrated

Almost every QA tester falls into this trap on their first real scenario: describing the feature by narrating the exact clicks a human would perform.

Scenario: User logs in
  Given the user opens the browser and navigates to /login
  When they type "alice@example.com" into the field with id "email-input"
  And they type "Passw0rd!" into the field with id "password-input"
  And they click the blue button labeled "Submit"
  Then the page at "/dashboard" loads
  And the text "Welcome, Alice" appears in the top-right corner

Read that again. It compiles. It runs. It even passes. But is it a business rule, or a recording of a mouse and keyboard session? It's the second one — and that distinction is everything.

Why This Is Bad

Brittle. Every one of those lines is coupled to an implementation detail: a field id, a button color, a corner of the screen. Change the login page's layout — move the button, rename the field, redesign the header — and the scenario breaks, even though the actual rule ("valid credentials log the user in") hasn't changed one bit. You end up "fixing tests" every sprint for a feature that never actually changed.

Noisy. The one fact that matters — valid credentials grant access — is buried under six lines of navigation and CSS selectors. A reader has to mentally strip away the noise just to find the rule being tested.

Useless as documentation. Gherkin's whole promise is that a Business Analyst or Product Owner can read a scenario and understand the rule without touching code. Nobody outside engineering cares what id the password field has. A BA reading the scenario above learns nothing about the business except that a login page exists.

The Hint of a Fix

Compare the click-script above to this rewrite:

Scenario: User logs in
  Given a guest is on the login page
  When they submit valid credentials
  Then they are redirected to their dashboard

Same rule. Three lines instead of six. No field ids, no colors, no corners of the screen — and it would still be true after a total visual redesign. That's the destination of this module: writing steps that describe what is true and what the user intends, never how they physically operate the interface. The next lesson breaks down exactly how to make that translation, step by step.

Pro Tip: If you can imagine a designer redesigning the page tomorrow and your scenario breaking because of it, you've written a click-script, not a business rule.

Key Takeaways