Pair Programming as an Automation Training Technique

There’s quite a demand for automation engineers. Unfortunately, as the demand grows, so has the difficulty in finding testers with automation skills. As of late, I’m seeing more of a push from companies to transition their existing testers into more of an automation role, and I’m also seeing a desire from testers to get into the space. This is great as long as there’s a mutual desire and investment from the tester and the business to go down this path.

A common question is how do we make the transition? An approach that I’ve used personally is to mentor the testers via pair programming. On one of the teams that I provided consultation for, there were no automation engineers. There was also no budget to hire automation engineers. Instead, they wanted to turn their existing testers into automation engineers. Initially, this seemed like quite the challenge considering the testers had no prior programming experience. In addition to being an automation engineer, I’m also a Java instructor, so for half a second I considered doing a series of Java bootcamps to train them but quickly realized this wasn’t practical. There was too much work to do, so I knew we wouldn’t be afforded an extensive amount of training time; and even if we were, the testers wouldn’t have a basis yet to apply this knowledge to. This definitely called for on-the-job-training!

I decided to take the approach of pair programming with the testers. I literally sat with them all day, every day for a couple of months and we automated their tests together. Of course in the beginning, I did a lot of the driving, but I also taught them while doing so. One benefit of using this approach was that they were only exposed to the parts of Java that they needed for automation.  This was great because Java is such a heavy language and not all of it is needed for basic automation testing. Occasionally, we’d run into the need to use loops or more complicated data structures like Maps, but in talking through each and every task and problem together, it helped them realize when and where they should use such concepts. It didn’t take long before they were driving and were able to clearly design how their automated scripts should flow.

Once the testers were comfortable enough to automate their scripts themselves, we continued to pair program but only for the more advanced topics. I intentionally became less forgiving of repetitive coding, and taught them how to refactor and streamline their code to promote reusability. I taught them how to think outside of whatever test they were working on at the time and recognize when their additions would make great framework utility enhancements instead that could be used by multiple tests. They basically learned to recognize design patterns and automate accordingly.

After a couple of months, we discontinued the pair programming sessions and these now automation engineers were able to work independently. But to continue the learning process, we introduced code reviews. These also serve as a great learning tool because not only are they learning from my feedback, but they are learning from each other as well. They’re able to see new programming techniques in a domain (the application) that they are already familiar with so it makes a lot more sense.

If your team is struggling to find multiple automation engineers, or you have testers who’d like to transition into automation roles, consider bringing in a very strong automation engineer who is patient and can serve as a pair programming mentor. This approach works great and has a quick return on investment. Good luck!