Everyday Exercise for the Technical Test Team

It’s easy to sign up for a gym membership, and it’s easy to say you want to grow a technical test team. The real value is in following through. Here are a few exercises to keep your test team going.

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 AutomationIt 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.

Pages

User Comments

4 comments

jorge castro

I would like to mention that after reading the article, one of the phrases that I liked most was this: "Offer a group of smart people any challenge and prepare to be surprised by the clever results" without any doubt I consider that team working ( Ex QA team, development team or others) is the key to be successful. I had that experience that the article mentioned, I did not have too much experienced with automation and also working many programming languages and I joined a QA team with awesome and skilled testers that worked with me as team, I learnt a lot from them and I tried to do my best but not for my specify project or my personal goals instead of that I tried to focus on development as a team and share our goals.

I think this is one of those articles that will be meaningful for many, many years. The technologies may change, and software development in general may go through many different changes, but the ethos of developing one's personal skillset, and that of the team, to embrace those changes will forever hold true.

I am only just at the beginning of this journey, learning my first language with a test team that is equally new to the automation world in general. We have a great dev team to help us when required. This journey is pretty daunting from my perspective, but I can't wait for that feeling that I've 'cracked it' to some degree, and for the same feeling with the team as a whole.

Bob, your arcticle is very inspiring for confirming to me how much I want to achieve this, so thank you!

About the author

Bob Jones

Bob Jones leads software testing at Chatham Financial, an interest rate and currency risk advisory company headquartered in suburban Philadelphia. He is an experienced automated test engineer and advocate of agile testing. When not mangling the Spanish language, he rides dual sport motorcycles and writes scripts in Ruby. Read Bob's blog at Leading Software Testing in an Agile World.