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!
Yves Hanoulle (@YvesHanoulle)
just to be sure I understand what you write
how is peer programming different from pair programming?
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. 🙂
Yves Hanoulle (@yvesHanoulle)
Interesting, peer review , training and quality is for me part of pairprogramming . That and knowledge sharing …
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.
What is the Best way to make this transition on your own. Any recommended websites or books. Currently work in QA but mostly Manual Testing .
Shevon, I recommend Alan Richardson’s book, Java For Testers.
Angie, I wish we had smart automation managers like you running our team…they just throw it at us, and have no concept of the depth and breadth of knowledge needed to become fully engaged and make a decent contribution.