As testers, we can take a few glances at any app or website and make a list of dozens or hundreds of things to validate. No matter the size and scope of a software application, there's a seemingly infinite number of scenarios to go through. And that's just on the user interface level, without knowing the intricate details of what's happening behind the scenes. On the backend, there are plenty of areas to test as well. At times, it can feel like QA work never ends.

Sometimes the complexity of our work as testers doesn't lie in the tools or tactics we use for our daily work to ensure quality in the applications under our care. Often, the difficult part of the job is knowing what needs testing. Ideally, we'd like to think that we can and should test everything we know and discover in a project. But that's not feasible or even possible, even with a solid set of automation practices at our disposal.

Each tester or organization will have its own thoughts and opinions on what needs testing and what can benefit the most from test automation. Most ways of thinking fall into two categories: those who focus solely on the "happy" path and those who want to dig deeper into all the "unhappy" paths and edge cases they can discover.

Neither approach is right or wrong, nor are they the only testing strategies available. Depending on your situation, you'll find different areas in your projects that require a specific or entirely different focus compared to similar projects. The applications, tools, and team will likely dictate how you automate your tests.

So how can you decide the right level of test automation for your applications? Let's see a common scenario and how these different testing mindsets apply. Then, we'll touch on some tips and tactics to help you move forward with your testing needs.

Testing the ubiquitous registration form

Anyone who's used the Internet in the past decade has come across a very common function on virtually every web application these days: the registration form.

This screenshot shows examples of various registration forms for different SaaS websites. Outside of the visual aspects of design and branding for each page, you'll notice that they have fields asking for similar information, either required or optional. These services will ask for your email address, a password, and other information like your full name, a unique username, and so on.

Imagine you joined a SaaS startup as an automation engineer and are assigned to automate some test coverage on their website's registration form. Registration is one of the first touchpoints for customers on any online service, and it's vital to ensure that this area works. If your customers run into issues while registering, they'll likely lose confidence in your company and bail, never to return.

Going back to the different ways of thinking about testing, you may approach this task in different ways (keeping in mind that these aren't the only routes you can take):

Focusing on the "happy" path

You might write a single test case that covers the entire registration flow from start to finish. You can only focus on filling out each field in the form with valid data, verifying that the customer can submit the form successfully, and nothing more.

Going deep into the requirements

You can also get into the nitty-gritty of the registration form and write different test cases to validate specific requirements. For instance, you might have short test cases for:

• Ensuring all required fields are filled before submitting the form.
• Checking fields that require a specific format like email addresses.
• Meeting specific password requirements.
• Verifying if someone has already registered with the same email address.
• Confirming the availability of the customer's desired username.

Which road should you take to automate?

In these examples, there are pros and cons to each approach. Covering the "happy" path is easier to write and maintain but won't verify any specific requirements in the form. Going deeper into an automated test can cover all your company's registration requirements but will require more time to automate and need more attention in terms of maintenance.

Regardless of the chosen path, both approaches end up with the same result—validating that the registration form works and customers can create a new account to use your service. Whether you went down a single route or branched out your tests, you'll have an identical outcome. Still, it doesn't answer the question about which approach you should take when automating a test.

Each tester has their beliefs on how to take on test automation, but in the end, what matters the most is whatever's the most important for your organization and its business.

If you work in a typical for-profit business, the most important thing is to make money to keep the business alive and growing. In the non-profit sector, the focus will be on the organization's mission. Based on your company's pursuit, you should always focus on your test automation with those goals. After all, if the company doesn't make money or have a purpose behind it, it wouldn't need this kind of work. Your testing priorities and strategies should stem from helping provide high quality throughout the entire organization based on its objectives.

Many testers spend too much time focusing on details that, while offering decent coverage, don't provide the most benefit out of their time. For example, is it essential to have automated regression tests to validate password requirements in a registration form? Is the registration form even worth testing in the first place? If you don't know whether it's crucial to the business, you may waste time on something that isn't needed. Focusing on what's important is what makes your test automation effective, not what tools or strategies you use.

Sometimes we may disagree with what's important. Usually, it's a combination of QA not fully grasping what the business considers most valuable and the business side not fully understanding the areas requiring a robust set of automated tests. Communication here is key to ensuring all stakeholders understand how to get the highest quality result at the end of the process.

Real-world strategies for test automation

The approach you'll take to write your automated test cases for your application will depend on multiple factors. Application size and complexity, team structure, external deadlines, security requirements, and countless other details will determine your best strategy. With that in mind, most QA teams follow a similar test automation path. Here are a few practical and effective strategies based on my experience across multiple teams and projects.

Use end-to-end tests only for the "happy" path

End-to-end tests are slower than most other forms of automated testing and require plenty of attention for long-term maintenance. These tests have a bad reputation because testers try to squeeze in too much coverage in their test suites, leading to sluggish performance and difficulty to keep running smoothly. Using end-to-end tests sparingly and going through fewer common areas will ensure your application works well while requiring less attention from a maintenance point of view.

For some, end-to-end tests are an absolute requirement because they provide a good layer of coverage across an entire system. In other cases, they're a "good to have" kind of test usually because of the complexities it can introduce. It's up to you and your team to determine if end-to-end tests are suitable for your project.

Go deep with unit, functional, and API tests

These types of automated tests are smaller, faster, and more maintainable than end-to-end tests, making them an ideal candidate for thorough coverage. Here, you can go through both the "happy" and "unhappy" paths in smaller chunks of the application with fewer worries about stability and upkeep. A good combination of unit testing, functional testing, and API testing will go far in keeping a high bar of quality for your applications.

Given that these tests are simpler to implement and execute, any software project should have a mixture of these tests written by developers and testers. Nowadays, software development tools and frameworks make it easier than ever to create these tests, so there's no excuse not to have some test coverage here.

Introduce other forms of testing as needed

Depending on the application under test and business requirements, it's worth exploring other automation tools and libraries when there's a need for more specialized testing. For instance, if performance is crucial for your application, add performance and load testing to your automation. Another example is implementing contract testing with microservices that communicate through APIs.

The key here is to add these types of tests when needed, especially in rapidly-evolving systems. For example, adding performance tests while a system is still under heavy development won't provide accurate results. You can begin setting up the tooling early in the process if you know you'll require them, but it's often best to add these after focusing on the other forms of testing mentioned above.

Summary

As an automation tester, it can feel overwhelming when joining a new project and you don't know where to start your work. Any application will have plenty of paths where you can immediately begin writing test scripts. How can you determine where to focus on getting the most out of your testing?

A good rule of thumb is always to tackle the business needs first. Many testers skip this step and end up building test suites that don't provide too much value for their work. Talk with your team and other project stakeholders to determine what's most valuable to the business and base your strategy on those high-priority segments.

When you know what's most valuable for the business and the organization, the time will come to begin the implementation portion of your work. Your strategy depends on your project and the surrounding situation. However, a safe bet is to go deep with easier-to-maintain tests while sprinkling in more extended end-to-end tests, so long-term maintenance issues do not bog you down. If your project requires it, add additional types of testing into the mix after focusing on getting a solid foundation with your main automated testing.

Remember, you can't test absolutely everything in an application, especially if it's an evolving system changing rapidly. Choose your spots instead of diving head-first to have a smooth and stable test automation experience.