2 Ways to Get Better at Test Automation
I see a lot of people in testing roles who want to fork their skill set so they are able to build some tests with code. I tried doing this early on in my career and had a hard time. My manager agreed to give me some time to build automation, but it was just a few hours here and there, nothing consistent. So I’d make a little progress, but then I’d spend a few days away and forget where I was and what I last learned.
I’ve since taken on a development role and become reasonably competent at building tests with code. If you want to do the same, here are two things you can do to get there, too.
Become a programmer
I think I spend more time testing software now, in a development role, than I ever did when I was a full-time tester.
When I make changes to my product back end, some unit tests have to be written or changed. If that back end is accessible to some third party, I have to write API tests. The front end gets unit tests and then some tests in the browser. After all that, I still need to open the browser and explore to see what logic I misunderstood, or how the workflows might not work for our customer.
Those unit tests on the front and back ends, API tests, and front-end tests are all forms of test automation, and I spend pretty close to half of my programming time in that area. The testing principles are simple, but working consistently in code has given me depth of experience.
I now understand not just automation tools, but product code. What I see in the product informs what tool I use and how I build tests.
Become an SDET
Some large software development organizations have a software development engineer in test (SDET) role. This person typically spends all day working in a testing framework, probably Selenium or Cypress, building tests against whatever UI changes were made in the last iteration. People in this role get very good at the testing tool they are using, and they will normally soak up a good bit of how their product front end works.
The next level of this role is a person who builds tools so that other people can test more effectively or more efficiently. These tools sometimes are changes to the PageObject to make automating the browser easier, sometimes help manage and create test data, and sometimes work with build systems so that all these tests can be run quicker and at the right time.
Everyone in a development team performs testing in their own way; testers don’t hold a monopoly on testing work. But automation is programming work. You need to be a programmer to understand the tools and the product you are testing. So, if you want to get better at automation, your best bet is to get into a role where you are dealing in code most of the day.