E2E (end-to-end) testing — this term is already very popular in software testers’ lives. I think it’s not just a trend, but more of a necessity for our daily work and especially for regression testing.
However, I noticed that many IT specialists have a different understanding of E2E testing, and I heard a lot of discussions around this topic. So, I decided to delve deeper into the E2E testing world.
I will try to summarise my observations and give you some advice regarding E2E testing.
What Is the Purpose of E2E Testing?
When you start using a new tool or methodology, you have to know how can it be useful and how it can help you to improve your project.
So what is the main purpose of using E2E tests? In short, it helps us to automate a particular user — flows from start to finish — and verify the system with interconnected systems as a whole.
Of course, I can choose the unit or integration testing types and create beneficial test scenarios. The difference is that by using E2E tests, you are simulating a real user scenario.
Imagine you are a user who wants to update his payment card data because your previous card has expired. One of the E2E test examples would be:
Login into the system
Navigate to your profile
Remove your existing card
Add a new card with valid credentials
Save updated info
Logout
In this example, you should use the call method for an already created login test case as your first step. Then, verify if the success message is displayed when you are saving new info. So, don’t forget to combine the steps from already created tests, but remember that the E2E test should be independent.
Keep in mind that E2E testing is not just a happy path testing — end-user can enter invalid credentials or use incorrect data, so pay attention when you are creating test scenarios. Hence, do not forget its core idea — by creating E2E tests, you need to act you were an end-user.
Unit, Integration and E2E Tests — Do We Need All of Them?
When we are talking about E2E testing it would be a mistake not to talk about other testing types — unit and integration.
E2E testing is the youngest child in this group, but how does it differ from other types?
Let’s say you need to test a username update in the user profile — save a new value. In the example below, you can see the differences between those testing types.
UNIT TEST. By using this type of testing you will create a lot of test cases to test if save function works well.
INTEGRATION TEST. You will be able to create separate tests that verify if a username is saved in the database after an update and is displayed properly in integrated systems.
E2E TEST. By using this type of testing you will create a user flow from start to finish — you will test if a user is able to log in, is able to navigate to his profile, enter a new value, save that information and see updated profile info properly.
There is no correct answer to which type of testing is better. Every type can be useful if you create effective test cases.
E2E Testing Strategy
E2E testing can be difficult to implement, so before writing E2E tests you need to think about the E2E testing strategy. In this section, I will provide some useful steps that can help you during the very first steps of the E2E test implementation.
System knowledge. Manual and automated testing share many similarities. You cannot start automation without the essential system knowledge unless you get a specific task, and your responsibilities are just to write the code.
If you are responsible for all of the quality processes in your project and you want to automate E2E tests, you should know the general key points about the system that you are going to write test cases for. So don’t be in a hurry, concentrate and when you feel comfortable about the end-user flows — it’s time for E2E testing.
Automated E2E test case structure. Another important aspect to start writing automated tests is the structure of test cases. Regarding your manual test cases and system domain you should decide how to divide automated test cases, for example:
critical functionality
basic functionality
edge cases functionality
What is the idea behind such structuring? From automated tests perspective — they can be slow and take a lot of time to run, so by separating tests into categories we can run critical automated tests in our CI build tool more often. This way we can get much faster feedback while leaving basic/edge case automated test cases on a daily run.
The importance of choosing the right tool/framework. One tool is not always fit for all the products we create. Nowadays we have a lot of automation possibilities. So before choosing the best solution to implement automated E2E tests, I suggest you prepare a checklist of criteria according to the scope of the project, resources and etc:
Maintainability — your system can change often and already automated user flows require to be updated from time to time. Automation testing should not be stressful and you should not investigate a lot of your time to update tests.
Built-in framework — E2E tests should be easy to set up. I always try to keep that in mind when choosing the tool with an already built-in framework because you can save a lot of time and effort.
Community support — I prefer using a tool with clear documentation and community support. If something goes wrong, you are able to get the answers fast.
Less is More. If you are familiar with testing types pyramid, you should know that when you are moving up that pyramid, your tests become larger in scale, but at the same time, the number of tests is reduced, meaning that E2E testing is not about quantity.
Conclusion
E2E tests are important — but you can’t rely on them only. Steve Freeman, the author of “Growing Object-Oriented Software, Guided by Tests” once said: “Running end-to-end tests tells us about the external quality of our system, and writing them tells us something about how well we (the whole team) understand the domain, but end-to-end tests don’t tell us how well we’ve written the code. Writing unit tests gives us a lot of feedback about the quality of our code, and running them tells us that we haven’t broken any classes — but, again, unit tests don’t give us enough confidence that the system as a whole works.”
So, do not forget to think from the perspective of your product — about its specifics, its challenges, and build your E2E testing strategy on that.
Top comments (0)