"I started learning about Selenium but don't know what I'm doing."

"Someone recommended I use TestCafe, but it's not easy to use for testing my API."

"My team jumped into using Cypress for our UI tests, but we're a bit stuck after realizing our app needs testing some functionality on multiple browser tabs."

Every week when I scan around different websites and forums around the Internet, I see automation testers making comments like these. Often, these comments come from people who are new to test automation. Most of this discussion often centers around one thing and one thing only: test automation tools.

Whenever somebody drops a post in a forum asking what test automation tool they should use for their work, tons of opinions start flooding in. If you've ever searched for "best automation tools" in any search engine, you'll find a seemingly infinite amount of lists and articles containing hundreds of options at your disposal.

It's overwhelming and confusing for someone new to automation, having to wade through so many comments and opinions, trying to make sense with how to proceed on their journey. Most of you have gone through this experience when starting. I know I did. I still do whenever I have to expand my skills to automate testing on different platforms.

Most of us tend to reach for tools first when doing something new. It happens not just in test automation, but almost every facet in our lives. When someone wants to create a podcast, they often research microphones before recording something with their laptop's built-in mic or even their smartphone. People wishing to learn to speak a new language buy tons of books and other materials before saying their first word. And automation testers usually ask which programming language or software to use before figuring out what they need to test.

Of course, you need tools to accomplish whatever you set out to do. You can't record a podcast without a mic, say something in a different language without reading or hearing it somewhere, or write an automated test without knowing how to code or use a codeless automation tool. However, starting your test automation efforts with tooling is a big mistake I've seen repeatedly.

Why jumping in with tools is a huge mistake

There's nothing wrong with sampling and experimenting with different test automation tools for your goals. As mentioned, you'll eventually need to use something to get your automation strategy moving forward. The main problem lies with how quickly some people jump into using any tool for their work.

A typical mistake I've seen by newer automation testers is when they start using a test automation tool. The tool works for a few of their basic scenarios, and they instantly go all in for the long haul. By itself, it isn't a problem if the tool covers all of the defined test cases. But usually, they'll realize the tool they chose won't work for everything they need.

When this happens, one of two things happens: the tester begins to try to make the tool fit their workflow to avoid sunk costs, or they have to backtrack and find a different tool. If they stick with their chosen tool, it'll lead to a brittle test suite and challenging to maintain. Otherwise, they'll have to go back to the drawing board with something different. In either scenario, they'll waste lots of time and effort.

The key here is to find the right tool for the job with your automation strategy before committing. The best way to do that isn't to focus on tools - it's learning about the application under test first, before anything else.

Learn what you're testing before reaching for tools

When you get distracted by the potential of shiny new test automation tools, you'll often lose sight of what you should spend more time thinking about - making sure you know how the application you're testing works. You'd be surprised at how much you can discover by paying attention to the details that make your app unique.

To go even further, you should also spend time learning a bit about the underlying tech running the application and how everything works. You don't have to do a deep dive and become an expert on every detail, but knowing what makes the application run will help with your testing efforts. For example, what kind of database does the app use? Does it connect to external services? Does it perform asynchronous tasks in the background? Knowing these details can help shape a better test plan that can consider specific scenarios based on what makes the app work as it does.

As you understand more about how the application works, you'll begin to think about the higher risk areas that can affect different parts of the app. What areas are most fragile and require more robust test coverage? For instance, if you discover that the app relies on third-party APIs to work correctly, you can make sure to include enough test coverage around this functionality.

You don't need to handle all of this on your own. The rest of your team is a treasure trove of information to help with your automation efforts. Developers can tell you which areas are most likely to break with new changes or new features that will modify existing functionality. Product managers can provide metrics that indicate which parts of the app most of your customers use daily. Having additional details from other departments can help you prepare better tests and avoid testing areas that don't matter in the bigger picture.

The more you know, the less time you'll waste

With some up-front work, you'll have a clear idea about how the app works both on the surface and internally, and you'll have "inside information" from people with in-depth knowledge of the app's current and future state. With all this information in hand, you can begin introducing test automation and tooling into the mix. By this point, you'll know which tools are the right ones for the job, and it'll save you and your team lots of time and effort with your automation work.

For example, imagine you're testing a web application with a sophisticated user interface or many moving pieces under the hood. You can choose a testing framework like TestCafe or Cypress and plan to write longer end-to-end tests to validate what you need. In another example, maybe you have an app with a simple UI, but the underlying APIs need more attention. An end-to-end testing framework may be overkill. Instead, you can use tools more suitable for API testing like Postman or SoapUI.

If you had immediately jumped in to test automation without knowing how your application works, you would have likely chosen the wrong tools for the task at hand. Focusing on API testing when it's best to ensure a complex user interface works well won't help your efforts. Only having unit tests when an application runs with different interconnecting systems like message queues, asynchronous background task runners, or separate microservices is also a waste of time.

Taking the approach of learning about what you're testing will take more time for you to get started. In today's fast-paced work environment, it may create disagreements in teams that want to get things done right now. But the time you spend learning now will save a lot of effort and frustration in the long run by focusing on testing the right things while avoiding spending too much time on what doesn't matter. Quality is a trait that builds and compounds over time, not something that's rushed for a quick result.

Summary

One of the first things that automation testers tend to do, especially those new to test automation, is to find tools to start creating a test suite. However, it's better to learn about what you're testing before you learn what you'll use to test.

Before reaching for the tools, start by learning all you can about how your application under test works. You have to learn how the average end-user interacts with the app to spot which areas are prime candidates for testing. This information will give you a starting point for your test plan.

Beyond the user interface, you should also take the time to learn the underlying components that make the app run smoothly. You don't have to know how everything works, but being aware of what's happening beneath the surface will give you more information on what to test.

Finally, take the time to talk with others outside of the testing team. Others who have more hands-on experience with the application under test can provide details no one else can give. If you stay inside your bubble, you'll miss out on this invaluable insight that can make your testing efforts easier.

You'll need tools eventually, but jumping in with tools first can lead you to pick something that you'll end up fighting against the whole way. Once you know what to test and which areas to automate, it becomes a lot easier to figure out which tools to use and how to implement them into your workflow.

What's your strategy when starting your automation testing efforts in a new project? Share your experiences in the comments below!