A browser test can show whether a customer can complete a journey, see the right information, and respond to feedback on a page. It follows interactions that stakeholders recognize, making it useful for demonstrating features and documenting how an application works. It can also check that components work together, but running every acceptance criterion through a browser makes the suite slower and harder to maintain. section 10.1 section 13.0
Choose a web test when the browser interaction is the point of the check:
- Illustrate a key user journey through the system. section 10.2.1
- Check which information appears, how it is rendered, or how a screen responds to a user action. section 10.2.1
- Verify business logic implemented directly in the interface, such as feedback displayed while a password is entered. section 10.2.3
Test the screen; test the rule separately
A registration test can enter an email already used by another member, then check for both an error message and a “Forgot your password?” link. Those visible responses justify a web test. By contrast, checking many password-strength or invalid-email cases through repeated browser submissions adds little confidence: use a few UI cases to establish the feedback, then check the remaining rules with lower-level tests. section 10.2.3 section 10.2.4
Rule: Duplicate usernames are not allowed
Example: Someone tries to register with an email that is already used
Mike Smith is an existing Frequent Flyer member.
His wife Jenny Smith does not have a Frequent Flyer account
Given Mike Smith is a Frequent Flyer member with the following details:
| username | smiths@example.org |
| password | correct-password |
When Jenny tries to register with a username of "smiths@example.org"
Then she should be presented with an error message containing "Email
exists, please try another name"
And she should also be presented with a "Forgot your password?" link
The registration scenario specifies the visible error and recovery link, not merely the duplicate-email rule. section 10.2.3
Selenium WebDriver can launch a real browser, click or otherwise interact with page elements, inspect the resulting page, and capture screenshots for reports or living documentation. In Java-based automation, meaningful element IDs or CSS classes help keep tests reliable; explicit or fluent waits let a test proceed when an asynchronous page reaches the expected state. Keep browser coverage selective: browser and environment failures can otherwise obscure application failures. For a legacy web application with little documentation, high-level web tests can also record existing behavior and help guard against regressions. section 10.2.6 section 10.5 section 13.0 section 16.6
