Business-Driven E2E Tests
| Table of contents |
|---|
- 2026-01-18 Text is published.
- 2023-10-14 Idea.
Introduction
End-to-End (E2E) tests simulate real user behavior by interacting with the application through its user interface. The idea is to test from the end user's point of view, who is using a web page, scrolling pages, clicking the links and mimicking the user interface as authentically as possible, to ensure the whole stack works.
Unlike unit or functional tests, E2E tests validate the system as a whole.
This article focuses specifically on how to design E2E tests so that they maximize business coverage while minimizing execution cost.
Problem
The idea of E2E testing is brilliant in theory but in practice there are some challenges: to create a testing environment where everything works as it does in production and to create as effective tests as possible because using the user interface, clicking links, waiting for the page to load etc. is a very slow process, so if there are lots of E2E tests and they are run every time new code is deployed, it can quickly become a deployment bottleneck.
In this article we focus on the latter problem: how to create effective E2E tests – from the business point of view. The number of permutations is close to infinite if the application is somewhat complex so testing all the different combinations is not an option.
Solution 1: Critical paths
One approach is focusing on critical user paths which means testing the most obvious user paths, for example in an e-commerce store, adding a product to the cart and going through the checkout is obviously a path that should always work.
Critical paths approach is a good first step but if higher the coverage is desired, a fishing net approach is more effective.
Solution 2: Fishing net
A fishing net approach refers to the idea where the application, for example an e-commerce store, is divided into logical components from the business point of view, such as different kinds of customers, products and actions that must work at minimum. In other words the fishing net approach models the application as a combination of business-relevant dimensions – customers, products, and actions – and tests representative combinations instead of exhaustive permutations.
Modern E2E tools such as Playwright make this approach practical by allowing tests to simulate different devices, browsers, and user behaviors so it's possible to create customers such as a basic customer who uses an updated Chrome on mobile viewport, accepts cookies and uses default choices throughout. The second customer can be opposite to the first one, not accepting cookies, logs in only when absolutely necessary and using less common browser. The third customer can use an international business customer using VAT-0 and English, and so on. It's a good idea first to list all relevant user settings there are and then combine them intelligently so that the most important settings are tested at least.
Different kind of products can be created in the same way. First list all the different properties possible of the products, then prioritize them and combine.
The customers or products that are created as presented above, can become imaginary customers and products that don't exist in real life but that's not a problem. The idea is not to mimic real users, but to systematically validate business-relevant properties, as effectively as possible. The same goes with actions: for example a normal user wouldn't seek the same product in many different places in a row but an effective E2E test can do that, to test all the different actions, at least tier-1 actions, that relate to product search, in one test case.
Below is a simplified example of how customers, products, and actions can be defined:
## Customers CUSTOMER-1 * Chrome * Mobile viewport * Accepts cookies * Logged in * Default settings all the way. CUSTOMER-2 * Safari * Desktop viewport * Rejects cookies * Logs in only when necessary * [SETTINGS-1] CUSTOMER-3 * Firefox * Tablet viewport * [SETTINGS-2] ## Products PRODUCT-1 * Physical * Available * Multi-category PRODUCT-2 * Electronic * Not available * Campaign PRODUCT-3 * Clearance * Heavy * Discount ## Actions TIER-1-ACTIONS * Go to the front page * Go to category page * Go to product page [PRODUCT-1] * Add a product to the cart from the main call-to-action button [PRODUCT-1] * Go to brand page * Add a product to the cart from the category page [PRODUCT-2] * Search ... etc. TIER-2-ACTIONS * Add a product to the cart using secondary ways. * Other secondary actions. ## Test cases TEST-1 = CUSTOMER-1 executes TIER-1-ACTIONS TEST-2 = CUSTOMER-2 executes TIER-1-ACTIONS TEST-3 = CUSTOMER-1 executes TIER-2-ACTIONS TEST-4 = CUSTOMER-2 executes TIER-2-ACTIONS TEST-5 = CUSTOMER-3 executes TIER-1-ACTIONS TEST-6 = CUSTOMER-3 executes TIER-2-ACTIONS
The key advantage of the fishing net approach is that when the plan is made, the developer can write the tests without needing to think what should be tested and what should not, and what is already tested in some other test case.
When the customers, products and test cases are created and documented, it's important to keep the list in sync with the actual code where the tests are written. If some test can't be created for a technical reason the code should still have a placeholder for the test telling the reason why it's missing.
Discussion
The fishing net approach offers several advantages. First, it's effective if the application is complex and testing coverage is wanted to get higher. Second, it's a straightforward approach for the developer because prioritization has already been done by someone else, a business representative. Also because the tests are defined from a business perspective, they often expose architectural or systemic weaknesses that would remain invisible in component-level testing.
E2E testing can be done manually as well, for example by giving every new employee a list of the actions to test or emailing a list to a random person every day to test this and that.
In more demanding environments where the system must endure high resilience, chaos engineering and red teams can be used (reference) (reference).