5 Strategical Steps to Optimize E2E Testing Layer in Any Project
In the continuous delivery, end-to-end (E2E) tests efficiently ensure the user experience remains unaffected by the changes. However, they often lack strategy and become unmaintainable, flaky, and unreliable which are common issues in UI automation. I’ve been implementing ideas to overcome these issues in my projects and identified the five crucial steps that helped me and my team to develop a robust strategy for the E2E testing phase.
Step 1: Stepping back to see the bigger picture
To write/maintain the E2E test layer, it is crucial to understand its place within the broader testing structure and what it represents across different testing levels. I find testing pyramids effective in visualizing the overall testing framework of the whole project. The below image shows the test pyramid in three dimensions: Test layer, test execution type, and quality attributes. GUI Workflow (E2E) Tests are at the top of the pyramid as they test the user-level behavior to determine if the product is usable as expected. They have the smallest part in the whole testing framework because they don’t involve the test cases already covered by the lower layers.
The purpose of the E2E test is to simulate the ultimate user journey, so it shouldn’t take time and effort to repeat the test cases covered in other test levels. They should be easy to run and maintain constantly. Therefore, if a test case has already been gone through in other layers of the pyramid, there is no need to test these scenarios in the E2E tests.
Step 2: Prioritizing the test cases
In the E2E phase, tests should be fewer than the other layers but with more comprehensive coverage. Therefore, filtering out the test cases helps optimize the testing suite, deciding which case needs to be automated first. It is essential to know your business domain well to determine what is important in your product. To achieve this, start by identifying the critical business values that require protection the most, and asses the risks associated with these business values. Then prioritize the tests that protect those risk areas.
This ensures that your testing efforts focus on mitigating the most significant potential impacts on the product’s success. For more insight on test case prioritization and risk-based testing, please check my article: “Testing FinTech: Risk-Based Approach in Automation”.
Step 3: Designing the automation scenarios effectively
As mentioned earlier, the test suite shouldn’t be large and bulky in the E2E layer and should consist of prioritized test cases. To have comprehensive coverage in these relatively smalltest suites, the most useful thing is to simulate the successful user journey for a particular feature.
The scenarios that simulate a positive user case (“happy paths”) are the most straightforward and expected flow of user interactions. Using positive test scenarios optimizes the E2E layer by focusing on the correct way of user interaction, ensuring that essential features are functioning correctly. One single happy path scenario is mostly enough to cover all the AC of the existing features and fails when the user cannot follow the steps as required. For this, collecting the successive test steps in a single test automation case makes more efficient work than tons of edge test cases. This approach gives a high level of confidence in the application’s basic behavior and helps to minimize the number of test scenarios.
Step 4: Building anti-fragile automation
Make sure that the tests are written and structured to pass if there is no bug in the application under test. Producing different outcomes means there are synchronization issues and the tests are nondeterministic. To have an anti-fragile test make sure that automation captures and waits for the elements correctly. Avoid explicit timeouts, and use wait methods for an expected step: element, API response, or a pop-up in the UI. You can check my article How to use Playwright Library for synchronized UI Automation for more insight.
Step 5: Increasing the Maintainability
In continuous development, the tester’s biggest challenge is constantly refactoring the tests whenever the functionality changes. So, the automation test code should be dynamically designed to be refactored easily. To achieve maintainability,
- Follow the single responsibility principle which makes it easier to change a test case if a business requirement changes.
- Reduce code duplication: implement setup and tear-down methods wisely, apply design patterns like Page Object Model, or try to create your own design pattern if your product requires a different type of implementation.
- Design the automation scenarios to run independently, the tests should not rely on each other in order to pass.
Conclusion
Adopting the right strategy in software testing determines what to deal with in the long term. It is crucial to acknowledge the importance of asking the questions “What should we test?”, “Why do we need to test it?”, “How should it be tested”, and “What value does this add?” while crafting the automation suite. The above-mentioned 5 steps provide a proper ground for asking these questions about the right things and at the right time.
