In an earlier article, I shared my team’s experiences as we embraced the concepts of whole-team automation. When building a team of automators, start with what you have. If you have existing tools and tests, use them. As a team, run your existing tests every day (or every build) and learn what works well and what doesn’t. If you are in the early stages of developing automation skills, pick a test framework and figure out how to use your tools as a technical user.
Very often, starting something is much easier than sticking with it. This is just as true for growing a technical test team as it is with gym memberships. At first, a couple pounds come off easily and you get interesting muscle aches. Motivation is high, and you scoff at others who fail to keep their exercise routines. During the initial period of automation high, you build new tests, and everyone is excited about the new skills. It is important to celebrate your early victories—those first bugs found by your automation feel great.
But real life can intrude and kill the passion. Sprint work, family life, and other interests all can get in the way. For continued success and growth, you need to plan time for automation (just like scheduling a regular time for the gym), and plan for more audacious goals.
As you plan time for these goals, you will develop a keen appreciation for the length of a work day. If you are growing the technical skills on your team, training takes time. If you are increasing the amount of automated test coverage, you and your team will spend a lot of time building and maintaining your tests and test code. An eight-hour day gets eaten up pretty fast. And depending on how much you enjoy what you are doing, nights and weekends may get eaten pretty fast, too.
Find Time Every Day to Code and Build Automation
It is important to exercise your coding and automation skills every day. On agile teams where all testers are automators, there may be conflict between the need to build automation and the need to keep up with the regular needs of the sprint team. If not carefully managed, this time conflict can lead to “mini-waterfall.” In our case, our desire to build automation led us to focus on automation during the first half of the sprint and then to catch up on the sprint testing at the end of the sprint. Taking time from the beginning of the sprint removed us from the most important discussions with our development teams and limited our impact on our projects. We worked ourselves into a position of being ”end-of-development checkers”—not good.
To solve this, we implemented an “automation hour”—one shared hour a day that everyone on the test team sets aside to work on automation projects together. We now work on our automation backlog evenly throughout the entire sprint, even during the busiest times of the sprint. We started automation hour simply to give us better discipline for developing our backlog of regression tests, but we learned that there are more benefits.
Before starting automation hour, the full test team rarely (if ever) worked together on projects. Our efforts were scattered across several sprint teams and focused on sprint goals. Our daily automation hour now gives us an opportunity to work as a team on a set of key testing capabilities that benefits the entire development organization. We cross train each other on new areas of our applications, giving the team greater breadth in our business knowledge. Also, we work together on hard automation problems. Less experienced automators work with more experienced automators. Because we work together, it essentially eliminates the need for automation standards documentation. Our consistent approach to automation is fostered by close collaboration and open communication. It is pair programming on the test team.