QA Automation is a specialized, niche field in the tech world. There’s not many of us, and it’s hard to find information about the tools you should use for the role. So, here’s a sampling of what tools work for me:
Python / Kotlin
You need a language for your test code, and it’s really helpful to use something with a productive environment and a light-weight syntax. On most automation projects, you need to move quickly and get test cases written before the next release. So, it’s really not a good idea to waste a bunch of time compiling code or fighting with incompatible libraries.
Python is an ideal language for an automation project because there is no “compile” step when you’re writing Python code. You write some code, and then you run it. If it does what you want, great! If not, change something, and run it again. And if you’re really advanced, you can use pdb or interactive mode to pause test runs and write and run chunks of code as you go.
If you work at a place that’s tied to the JVM ecosystem, Kotlin is a really attractive option. It has a minimal amount of syntax, some very modern language features, and it can seamlessly use packages from Java. It even has a scripting mode to skip the compile step.
For your next automation project, try picking one of these languages, or something similarly productive. Just try to avoid picking Java. I see a lot of automators writing tests in Java, and it makes me sad. There are better options out there, people.
Selenium / Appium
Once you pick a language for your test code, you need a library to allow you to talk to the application under test. I’ve seen some really interesting projects lately. But the standard of practice for a UI integration test is still Selenium and it’s mobile variant, Appium.
Are Selenium and Appium perfect solutions? Absolutely not. But they are the most widely used, and most broadly compatible libraries, and they are the best place to start when you need to automate some UI tests. Start with these libraries, and if something isn’t quite working, then start looking at something else.
Py.test / JUnit
After you get some code talking to a web browser or a mobile device, you’ll need a way to structure the code into the classic setUp / test / assert / tearDown format.
For Python, Py.test is the best test framework. It gives you a lot of options, and it has the most community momentum, by far. For Kotlin, there are several good choices, but I still like tried-and-true JUnit.
MoxProxy / ZAProxy / AnyProxy
In some test scenarios, you need a way to look at the network traffic going between the application and the back-end. There are a few proxy tools with a programmatic API that lend themselves very well to automation.
I highly recommend MoxProxy, ZAProxy, or AnyProxy. They all have a lot of useful features, and they’re easy to integrate into your code. Another project called BrowserMob Proxy used to be the standard tool, but it hasn’t been maintained in years, so try looking at something else first.
Locust.io / Wrk / Gatling / JMeter
With Locust, you write your load test scripts in standard Python code. No special syntax or configuration formats to learn, and it offers a lot of configurability.
Jenkins / GitLab CI / GitHub Actions
Now that you have some automated tests written, you need a way to run those tests regularly, on a defined schedule. Consistency is a pillar of quality engineering.
Jenkins has been the standard tool of continuous integration for years, and it has plug-ins to cover most of the standard workflows with minimal work. Jenkins is a good tool to learn if you need more control over your continuous integration server than you can get with Travis or Circle CI.
The new trend for development teams is to use a service that combines version control, issue management, and continuous integration in one place. So, it’s a good time to start learning GitLab CI or GitHub Actions. It’s pretty much like Travis, but stuffed into a tab near your project repository.
What’s In Your Toolbox?
These tools are what I use every day for my test automation projects, and I’m always looking for new alternatives. Part of being a good quality engineer is knowing your tools well, and understanding which one to apply for a given test scenario. Don’t make the mistake of having one “hammer”, and treating every test automation problem like a “nail”.