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.

Get Your Geek On—Learn Another Language
Living the life of a technical tester does not mean simply being a top-tier automated test tool jockey. Of course, being the best you can be with the tools you use is good for your career. However, do not limit your view of test automation or technical testing to just those tools.

Great agile software testers are software developers. Unfortunately, many are not proficient with even a single programming language. Andrew Hunt and David Thomas write in The Pragmatic Programmer that top-tier software developers set a goal to learn a new programming language every year. I am not sure how many act on this goal, but I love the idea of the high standard for their professionalism. We, as professional testers, have a huge gap to close.

Thankfully, our team developed very good skills using HP’s QuickTest Professional (QTP). And, of course, to do anything meaningful in QTP, you must write good code in VBScript and apply solid software development practices. However, your credibility as a technology geek is weak if your only language is VBScript. You need to learn some cooler languages.

One of our goals (aside from the increased respect from our developer friends) was to take advantage of and eventually contribute to open source test projects. We set a goal to learn Ruby, an open source language that has support for test applications such as Watir and Selenium and has great potential for helping us solve many of the day-to-day problems that testers encounter.

Learning a programming language is one of those endeavors where hard work wins the day. It doesn’t matter if you studied computer science or English in college (or if you are a 12-year-old). When our team set off to learn Ruby, we didn’t let the fact that none of us knew Ruby slow us. We bought copies of Brian Marick’s Everyday Scripting with Ruby for Teams, Testers, and You for everyone on the team, and we scraped together the rest of our Ruby training from the Internet.

Becoming competent in programming is not something that can be easily sneaked into the work day. In my opinion, the ability to program is a core competency for professional software testers, and as such, it each tester’s responsibility to maintain his professional skills. In our case, we did spend some work time on our training, but the majority of time was our own, working on exercises at night and meeting before work and at lunch to review and discuss new concepts.

The Smalls Are Huge
After devoting shared time to grow these new skills, it was important to find and celebrate practical ways to use the skills—and, rather than looking big, to look small. A tester’s day is filled with small issues and inefficiencies, and solving these small problems is key to our everyday life with test automation.

In Everyday Scripting with Ruby, Marick builds a case for using Ruby as a solution for creating small utilities to enhance productivity. He specifically stays away from GUI automated test frameworks and, instead, solves and addresses solutions to less sexy problems such as verifying that an uninstall script actually removes everything it is supposed to remove and how to get notified when a long-running process completes.

In our shop, we use QTP as the primary automated test-execution tool. It is a powerful tool, but there are opportunities to make life easier without consuming an expensive license. For example, sometimes tests or test resources are locked by other users or application crashes. One of our favorite smalls is a utility that lists all the QTP locks and enables you to select and unlock a test or library. This small is a huge time saver.

We have developed other scripts that consolidate test results, parse result values to make renorming tests easier, convert data into regular expressions, and help with services testing. As you do this, make a point of celebrating the small wins. Innovation rarely happens with big leaps. A steady stream of small innovations will take you far, build confidence, and maintain a level of excitement.

Ruby Challenges
Smalls are great, and we look for them and celebrate them whenever we find them. But as great as they are, they are not common enough to drive the training and growth of the entire test team. To give everyone opportunities to learn new things, we rely on Ruby challenges. Every few weeks, we share a programming challenge with the team and encourage everyone to write a script, algorithm, or function. These challenges give everyone on the test team another reason to work together and to grow skills.

On our team, a core group participated in the initial Ruby study group, while others did not. I worried that those who did not participate in the study group would not get anything out of the challenges, but the team surprised me. Dangle an interesting puzzle in front of smart people and they will find a way to work on it. Here is one such puzzle:

A farmer has a forty-pound rock that he uses with a balance-type scale to measure grains and feed. He lends that rock to a neighbor, and the neighbor accidentally breaks the rock. It is broken into four pieces. He returns the rocks to the farmer and is very apologetic. The farmer, unexpectedly, is pleased. He says with these four pieces of rock and the balance-scale that he can now measure everything from one to forty pounds. What is the weight of each rock?

The answer to the riddle doesn’t really matter. Here is the challenge: Using Ruby (or some other programming language), write a script that tests your guess.

As a bonus, write an algorithm that derives all the possible combinations of stone weights.

Bonus points for elegant code.

Offer a group of smart people any challenge and prepare to be surprised by the clever results. That’s the best motivation around.

The results of our technical activities—automation hour, learning new languages, development of smalls, and programming challenges—help to shape the attitude of the team. These results give everyone confidence to tackle hard problems and look for innovative solutions to problems in software testing. It has served to expand our world, and we now have more options. For example, we can choose to stay with our vendor solution, to move to an open-source tool, or to write our own solution. The choice is ours.