These days, you can get pretty far with having a full test automation suite without knowing how to code. Whether you're testing websites with Selenium IDE or iOS apps with XCUITest, you'll be able to find tools that make testing a snap. These tools allow anyone to load their application, perform a few actions, and BAM - an automated test is ready to go.

The ease to get a full-blown test suite start, however, comes with a few limitations. These tools are great for starting, especially when you're building your testing chops. However, they inevitably become more of a hindrance than a help. It's rare to find a tester who begins using these tools, only to find themselves cursing under their breath wishing they never met it.

Some of the more common issues that these recording tools have are:

• Test suites take forever to run. Many of these tools set less-than-ideal default settings on how to execute certain steps. For example, selecting an element on a website can take longer because you have to wait for the page to load entirely. Another example is filling out fields in a form might be as slow as someone typing and has never used a keyboard before.
• Tests become inconsistent and flaky, failing for no reason. Since the test was just a series of recorded steps, you'll often have no idea why the test failed. The tools themselves offer very little help in the form of debugging methods like error logs.
• Specific interactions might be tricky to perform. This problem is especially evident in websites that have plenty of interactivity, like dragging and dropping elements in different areas.

If you're loading a simple application, clicking a few things, and running a few basic assertions, these recording tools might be enough for your needs. However, eventually, you're going to find that you need more control over your test automation. That's where coding comes into play.

Coding up your test suite

The best way to have full control over your test suite is to code the tests yourself. Doing the coding takes longer than simply clicking around. However, instead of being at the whims of whatever the recording tool chooses to do, you'll wield complete power over the test. You can determine precisely what you want the test to do, not assume that the tools do it for you. Coding instead of using a recording tool often end up with a more stable test suite since you'll know what's going on.

If you've never done any programming before, admittedly this can be a difficult task in itself. If you search online for "What's the best language to use for test automation?", you'll be bombarded by a seemingly infinite amount of choices. It's easy to get overwhelmed by the selections you'll have at your disposal.

Given so many options to choose from, how can you even begin to pick one? Simple choices are better, and I have one choice you can use when faced with this issue to get you moving forward with your learning adventure.

The best way to choose a programming language

If you want or need to start learning to code, the most reliable choice is simple: use the primary programming language the developers building the application are using.

By using the same programming language the development team on your project is using, you'll make the difficulties of learning to code easier on you. You'll have a much easier time during the learning process. Also, as a bonus, you'll have a smoother time building and maintaining your test suite in the long run.

When you express a desire to learn to code, most developers are more than happy to help you on your journey. The majority of humans feel the need to share their knowledge in some shape or form. If you use what they already know, I guarantee they'll be helpful with the process. Having access to people who have plenty of experience and their availability to help out is invaluable.

Interestingly, this also has a long-term effect. Many developers might have some experience writing tests in a smaller scope like unit tests but have never paid attention to other testing strategies like end-to-end tests. Once you begin to get a grasp at programming and start writing automated tests, you can begin exposing this practice to the development team.

If you use a completely different programming language from the rest of the team, it can accidentally create a silo of sorts between testing and development. This rift actively discourages collaboration between teams and makes your job as a tester much more complicated than it should be. But if your tests are in a language they can understand, it encourages everyone to dip their toes into the world of broader automation testing. They'll feel responsible for improving and maintaining the health of the test suite.

Don't fret over-thinking if your choice is the "right one." No matter which programming language the developers use on your team, you shouldn't have any trouble finding the right tools to use. These days, most modern programming languages have libraries or frameworks that allow you to write automated tests. For example, Selenium WebDriver has support for many programming languages like Python, Ruby, and C#. Newer frameworks like Cypress and Testcafe use Javascript, which is a must-have language skill for web developers nowadays.

Exceptions to the rule

As with any choice, this is not a "one size fits all" deal. There are exceptions to this rule, so you shouldn't blindly pick whatever others on your team are using.

The primary consideration you should have is the application under test and what you want to test. Different apps and testing goals require different tools. For example, let's say your main goal is to create an end-to-end regression suite for a web application. For this use case, choose a test framework that makes it easy to create tests rich in browser interactivity. In the event you want to test the performance of an API, you'll want a tool that helps you create load or stress tests with ease. Some programming languages may serve better in some cases than a general-purpose language.

You also need to take into consideration other factors beyond writing tests. Any test suite needs additional setup to run under the appropriate circumstances. For instance, will your tests need access to a database or external service? Perhaps you need to create a particular test environment to run the tests? Some programming languages are better suited for some of these scenarios. So take some time to consider the scope of your the entire test suite, from start to finish.

Most of the advice in this article points to checking in with your team for a clearer path forward. However, what if you're working solo? If that's the case, you're free to choose whatever you want. Pick what interests you if you want to learn something completely new and have time for studying. If you want to get things running as soon as possible, select something you're comfortable using. Your choices are open but still take time to use some of the advice written here to guide you to a selection.

Pick one, move forward

Eventually, you'll have to pick one thing to move ahead. There's a lot of different options out there, and it's easy to spend days, weeks, even months trying to come up with a single choice. Whether it's fear of choosing the wrong thing or feeling like you don't have enough information, don't linger too much on your decision. I've seen many people - myself included - spend too much time deciding which route to take when learning something new. That's time you won't get back. The worst decision you can make at this point is not to decide at all.

That's not to say to just randomly choosing something. You shouldn't choose as if you were blindfolded and throwing a dart to a dartboard of possibilities. Take time to do some research, but limit it to just a few hours. Pick what feels serves you best with the information you have, and start testing as soon as you can. Worst case scenario, you'll realize that your choice doesn't serve your purposes well, and you can move on. Still, it won't be wasted time because you'll still learn something. It equips you for making better decisions not just for what you want to learn, but what's a suitable candidate for your needs.

With your choice in hand, you can confidently begin your journey into the world of stable, efficient, and speedier test runs. It can be a bumpy road, but the payoff is worth it for you and your team's project.

Photo credit: Dave Clubb on Unsplash