An approach to refactoring test automation

For one of our products, we’ve been using the same front-end test automation suite for several years. We currently have ten testers across five different agile teams who contribute code, and the total number of contributors through the life of the suite must be over 100.

As with any suite of similar history, our implementation varies greatly between different functional areas of the product. Though the coverage decisions are relatively consistent, the way the code is written is unique based on who the author was. These differences are visible through all layers of the suite: in the plain English concordion specifications, our accompanying Java fixtures, and supporting WebDriver utilities.

From mid-December to late January our product is put into a release change freeze. This is the summer vacation period in New Zealand, many of our staff away on leave, and due to Christmas it’s one of the busiest banking periods for our digital channels. As development of new features slows, it’s the perfect time to focus on activities like refactoring our automation!

In mid-December I ran a brainstorming session for the testers of this product to identify the technical debt in our associated automation. We quickly came up with a list of over 20 high-level items including standardising the implementation of common actions, creating naming conventions, removing duplication, consolidating utility classes, and improving documentation.

We voted on those that were most important and two items emerged as an immediate priority:

1. Standardise how we use waits
2. Determining a consistent approach to login

I scheduled two coding dojos prior to Christmas and these two priorities became the objectives for these sessions. The dojos were scheduled for two hours on a Tuesday, each with 8 or 9 testers participating in the traditional dojo format where:

• The facilitator asks questions and doesn't give answers
• Everyone must participate in the code being written
• Everyone must take a turn at the keyboard

Prior to each dojo, I created a refactoring branch using git. During the dojos we made changes against the branch, generally working on a single specification and associated fixture that I selected in advance. We collectively agreed on what our standard approach would be by making the first set of changes as a group.

We were working on a framework that the team use on a daily basis, so every attendee had good knowledge of the code. There were different opinions about the right way to do things; refactoring created a lot more discussion than when we used the dojo format to extend a framework into new areas. The testers were engaged in the process and stayed invested in the outcome throughout each of the two hour dojos.

After each dojo, I pushed our changes to the refactoring branch so that the testers could pull the work we had completed. Then I created a backlog of related refactoring tasks. Through the remainder of the week I asked each tester to independently pick up a task from this focused backlog so that they could immediately apply what we had decided as a group by refactoring with the same purpose in another area. Each task doubled as both a learning exercise and a way to improve our suite.

Each person who claimed these tasks worked on the same refactoring branch and pushed their changes when complete. At the end of the week, once all the backlog tasks were finished and committed against our refactoring branch, we merged our changes back to master via a peer-reviewed pull request that included the entire test team and a few developers too.

Branching strategy for refactoring via coding dojo and shared backlog

Using dojos as a tool for collaborative refactoring has worked well for us. During the session, the high level of prior knowledge of the code has created a healthy environment for discussion. The team have been passionate but flexible, and able to establish agreed standards relatively quickly.

The granular introduction of consistency in our automation gives us time to understand each decision being made and to create associated documentation with refactoring examples in our expanding how-to library. The huge amount of tidy up to be completed seems more manageable when we tackle small pieces. Using dojos makes it feel like everyone is across the desired solution rather than just a couple of people championing “the right way” to do things.

During the week following each dojo, having all the testers working on a common backlog of refactoring tasks against a single branch of the code has improved collaboration. The testing chat channel has been noticeably more active! Because the testers usually work in five different delivery teams, on five different functional areas of the application, it’s unusual for them to have to interact with such regularity.

Regular coding dojos have been the cornerstone of an inclusive, engaging and collaborative approach to refactoring our test automation.