Pair Programming as an Automation Training Technique

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!

Angie Jones

8 Comments

Angie Jones

Yves, I view it as a combination of pair programming and peer review with an emphasis on training vs quality assurance as the purpose of the activity. But don’t read too much into it; it was not my intention to define a new term. 🙂

Angie Jones

In its original form, I think of pair programming as two programmers who both know what they are doing equally contributing to the coding and ideas behind it. The “passenger” would also be looking out for mistakes and potential bugs.

I guess what I’ve described here is pair programming but with a different intention. The passenger here is not yet a programmer and is peer reviewing in an effort to become one.

I’ve learned automation through pair (and mob) programming. The difference, however, is that while trying out traditional pairing, I would just let my frustration win and stepped out mentally, more focused on the actual testing I could do if I wasn’t automating. Bringing in Strong-Style Pair Programming (“for an idea from your head to the computer, it must go through someone else’s hands”), I would be the driver and in control of the keyboard, and the more knowledgeable automation engineer would be my navigator, giving me just enough to keep us together working on the task. I found that concepts (like loops and maps, and keyboard shortcuts) stuck with me much faster as I was using them, not just looking at someone using them.

With Selenium tests, I’ve had great experiences of me coming in with an idea, and navigating a more experienced programmer in implementing that refactoring things to page-object pattern. In those cases, I find that just using timer to switch roles in pair develops our shared understanding nicely.

Subscribe to Newsletter

About Angie

Angie Jones is a Senior Developer Advocate who specializes in test automation strategies and techniques. She shares her wealth of knowledge by speaking and teaching at software conferences all over the world, as well as and leading the online learning platform, Test Automation University. As a Master Inventor, Angie is known for her innovative and out-of-the-box thinking style which has resulted in more than 25 patented inventions in the US and China. In her spare time, Angie volunteers with Black Girls Code to teach coding workshops to young girls in an effort to attract more women and minorities to tech.