End-to-end testing (E2E testing) is arguably the most misunderstood type of software testing out there. It’s also one of the most important ones. Why? Because it’s the type of testing that most closely resembles the experience of a real user working with the application.
We’ve already published an introductory guide to E2E testing. Today, we build on that guide with a list of seven end-to-end testing best practices you can adopt right away to take your E2E testing approach up a notch.
1. Leverage Test Automation
If you can automate something and you plan on repeating it, you probably should do it. Many aspects of software testing can be automated, and the benefits of automating your testing strategy are plenty. But if I had to pick a single reason to convince you, I’d say you don’t really have a choice.
The modern software industry moves amazingly fast. To stay alive and competitive, organizations need to deliver high-quality software quickly and reliably. Sadly, software applications are highly prone to regressions (i.e., even a small change could cause unforeseen consequences in another area). You can only be confident in the quality of the code you’re shipping if you retest the entire application every time someone makes a change to it, no matter how insignificant it seems. Sound doable?
At the end of the day, if you still want to release software on time, you’re left with two options: You either don’t test your app (or maybe test only a fraction of it) or you leverage automated testing to have your cake and eat it, too. Which one do you prefer?
2. Leverage Codeless Test Automation
There is a variety of types of automated testing, and many, if not most of them, require coding skills. There’s nothing wrong with that, per se. For instance, unit testing is a code-based form of testing. And there’s no reason why it shouldn’t be that way since developers write them to check their assumptions about their code. However, this is 2020, and the current answer to the question “who performs software testing?” includes many more roles than just developers. Instead, a variety of professionals might be involved in testing, and they may or may not know how to code.
Speaking specifically of E2E testing, being able to create test cases without relying on code is a huge advantage. Codeless test automation allows you to get help from testers and other professionals without coding knowledge. This frees developers from having to create code-based test cases, allowing them to focus on delivering new features or fixing defects.
But as a caution, you need a codeless testing solution that is flexible enough to allow code when you need it. Why? Because you can’t anticipate the changes that you will make to your application and having the ability to insert custom code into a step, helps future proof your testing. You might need help from a developer to write some of the custom code, but you won’t need to replace your tool.
If codeless E2E testing sounds like a good idea, you might want to give Testim a try.
3. Select Page Elements the Smart (a.k.a. Stable) Way
Asynchronous loading of elements is a common feature of many modern web applications. This presents a challenge when automating E2E tests since attempting to interact with an element that’s not yet available results in errors in most testing tools.
There are ways to counter this challenge. For instance, if you’re trying to find an element in Selenium and getting a NoSuchElementException, you can tell your test script to wait, either for a fixed amount of time (implicit waits) or until the desired element meets some criteria you define (explicit waits). However, asynchronous loading of elements isn’t the only way in which page elements can be challenging. Changes to their attributes—such as ID or name—can lead to brittle tests.
To avoid that, you can leverage strategies that create more robust selectors for page elements. For instance, instead of trying to find elements by CSS selectors that can change at any time, you could apply custom data-* attributes created exclusively for testing purposes to the elements (for instance, data-test:<unique-value>).
Another alternative would be to adopt a testing tool that offers smarter selection strategies out of the box, such as Testim, which offers a smart locator feature that helps identify elements using more than a few attributes. So when element attributes change, they don’t break the tests.
4. Leverage Risk-Based Testing
When you first start implementing your testing approach, you might feel the urge to test everything. In principle, that’s not a bad idea. Attempting to achieve high test coverage is a worthy goal. Realistically speaking, though, we know you have scarce resources. Even after leveraging automation at all testing levels, testing everything is still difficult. That’s where the concept of risk-based testing comes in handy.
Risk-based testing is an approach to software testing that acknowledges that not all parts of the application are created equal but, instead, differ in several criteria. For each part of the application, analyze factors such as code complexity, how critical that area of the application is for the line of business, and how often it’s changed, among others. That way you can figure out which parts of the application are simultaneously A) more likely to get defects introduced to them, and B) would cause the most harm had they been broken. You can then concentrate your testing efforts on those areas, at least in the beginning.
5. Test at the Right Time, in the Right Order
What to test and how to test are two essential decisions you need to make when designing and implementing your E2E testing strategy. The already mentioned risk-based testing approach can answer the “what” question. You’ve already seen the “how,” too, when we discussed the second of our end-to-end testing best practices: codeless test automation.
But what about the “when”? The concept of shift-left testing might have the answer. This concept is all about moving performing testing earlier in the software development lifecycle (SDLC). By avoiding approaches where software testing is only carried out at the end of the SDLC, you can obtain feedback sooner, which in turn means you can diagnose and fix defects when it’s cheaper to do so. So, how does E2E testing fit into the idea of shift-left testing?
It fits perfectly, as long as you understand the importance of testing in the right order. It doesn’t make sense to try to perform E2E tests when developers are first developing the features. At that early stage, developers will be creating unit tests—either by writing them after the production code is completed or by applying test-driven development (TDD). Alternatively, the team might employ behavior-driven development (BDD), but the principle remains the same: There’s no way to apply end-to-end testing before both ends are complete!
So, one of the end-to-end testing best practices we’re listing here is to test in the right order. Since unit tests give the most precise feedback when they fail, you should have unit tests from the get-go and run them before any other type of test. That way you can catch bugs when they’re still easy to fix.
You should create E2E test cases after each feature is ready to go. Since E2E tests tend to be slower and more complex, you should execute them last and only execute them when the earlier types of testing don’t catch anything.
6. Ensure You Have Proper Test Data
It doesn’t matter how great your test cases are if you feed them poor data. You must ensure your tests get high-quality data in suitable quantities exactly when they need it.
Just copying data from production and calling it a day might sound like a good solution, but doing that has plenty of problems. For starters, production data might lack representation of edge-case scenarios that need to be tested. It also might lack data for recently added database tables. The most egregious risks are the risk of exposing sensitive data such as personally identifiable information (PII) or business-sensitive data.
That’s why you need a solid test data management (TDM) process. You can go with the approach of automatically generating test data, which is generally recommended. If you do need to resort to production cloning, make sure to employ data masking capabilities to prevent sensitive data leaking to non-production environments.
7. Always Keep the User in Mind
Make the final user front and center in your testing efforts. This is arguably the most important piece of advice in this post.
When designing E2E test cases, try to put yourself in the user’s place. What are they trying to achieve? Can they easily reach their goal? To answer questions like these, you have to develop a deep sense of empathy for the final user, which isn’t an easy thing to do.
A useful technique might be involving stakeholders in the requirement analysis process. If your company already applies BDD, for example, you might use the specifications it generates as inspirations for creating user-centric test cases from the very beginning.
The Beginning of Your End-To-End Testing Journey
End-to-end testing is one of the most important types of testing you can have in your QA strategy. Unfortunately, it’s also one of the most misunderstood. People dismiss its relevance, mistake it for other types of testing, and even outright encourage people not to do it.
This post was yet another contribution to clarify the many misconceptions revolving around E2E testing. By applying this list of end-to-end testing best practices, you’ll improve your E2E testing approach and deliver software in a timely, consistent, and reliable fashion.
