Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

Knowing that test automation and continuous integration were key, the teams at DoubleClick came up with new ideas, such as a specialized build and automation team to help the development teams cope. They brought in expert training to help them learn TDD and pair programming. They started taking steps to address their legacy system’s technical debt.

Tae’s team attends all of the sprint planning and review sessions, using both formal and informal communication to facilitate cross-functional communication and coordinate testing and releases. He has found that it helps to keep meetings small, short, and relevant. He’s also a proponent of everyone sitting together in an open work area, as opposed to sectioned-off cubes.

Tae offers the following advice to testers making the transition to agile:

“Agile development in general will initially frustrate testers in that they will not have access to full requirements documentation or defined stages of testing. In my view of agile development, at any given moment, the tester will be engaged in tasks from multiple stages of the traditional development process. A tester can be sitting in a design session with engineering and product management (she should be taking notes here and start thinking of areas of risk where proposed code change will most likely impact) and on the same day work on automating and running test cases for the proposed changes. It’s a change in mind-set, and some people are quicker to adapt than others.”

Tae’s experience mirrors our own and that of many other teams we’ve talked to.

If you’re a QA manager, be prepared to help your testers overcome their frustrations with moving from defined, sequential testing stages to fast-paced iterations where they perform widely varied tasks on any given day. Help them adapt to the idea that testing is no longer a separate activity that occurs after development but that testing and coding are integrated activities.

If you’re a tester or other team member who isn’t getting the support you need in your transition to agile development, think about the difficulties your managers might be having in understanding agile development. Help them to understand what kinds of support you need.

Speaking the Manager’s Language

What do business managers understand best? It’s the bottom line—the ROI (return on investment). To get the support you need from your management, frame your needs in a context that they can understand. Your team’s velocity translates into new features to make the business more profitable. If you need time and funds to learn and implement an automated test tool, explain to management that over time, automated regression tests will let your team go faster and deliver more functionality in each iteration.

Lisa’s Story

My team needs big blocks of time to do risky refactoring, such as trying to split the code base into multiple modules that can be built independently. We also need time to upgrade to the latest versions of our existing tools, or to try out new tools. All of these tasks are difficult to integrate into a two-week sprint when we’re also trying to deliver stories for the business.

We explained to our management that if these “engineering” tasks were put off too long, our technical debt would accumulate and our velocity would slow. The number of story points delivered each iteration would decline, and new stories would take longer to code. It would take longer and longer for the business to get the new features it needed in order to attract customers.

It was hard for the business to agree to let us devote a two-week iteration every six months to do the internal work we needed to manage our technical debt, but over time they could see the results in our velocity. Recently, one of the managers actually asked if we might need to have “engineering sprints” more often. Both the product and the team are growing, and the business wants to make sure we grow our infrastructure and tools, too.

—Lisa

Like all members of an agile team, managers need to learn a lot of new concepts and figure out how they fit as team members. Use big visible charts (or their virtual equivalents, as needed) to make sure they can follow the progress of each iteration and release. Look for ways to maximize ROI. Often, the business will ask for a complex and expensive feature when there is a simpler and quicker solution that delivers similar value. Make sure you explain how your team’s work affects the bottom line. Collaborate with them to find the best way for stakeholders to express the requirements for each new feature.

Budget limitations are a reality most teams face. When resources are limited, your team needs to be more creative. The whole-team approach helps. Perhaps, like Lisa’s team, your team has a limited budget to buy software, and so you tend to look at open-source test automation tools that usually don’t have a large up-front purchase cost. A tool that uses the same language as the application won’t help the non-programming testers unless the programmers collaborate with them to automate the tests. Leveraging all of the expertise on the team helps you work within the business limitations.

As with all challenges your team encounters, experiment with new ways that the development team and management can help each other to build a valuable product. At the same time, regardless of your development approach, you might have to make sure that some processes, such as conformance to audit requirements, receive the necessary attention.

Change Doesn’t Come Easy

Agile development might seem fast-paced, but change can seem glacial. Teams that are new to agile will be slow to master some practices they’ve committed to using. We’ve met many testers who are frustrated that their “agile” development cycles are actually mini-waterfall cycles. These testers are still getting squeezed; it just happens more often. Iterations are over before stories can be tested. Programmers refuse or aren’t able to adopt critical practices such as TDD or pairing. The team leaves responsibility for quality in the hands of the testers, who are powerless to make changes to the process.

There’s no magic that you can use to get your team to make positive changes, but we have some tips for testers who want to get their teams to change in positive ways.

Be Patient

New skills such as TDD are hard. Find ways to help your team get time to master them. Find changes you can make independently while you wait. For example, while programmers learn to write unit tests, implement a GUI test tool that you can use with minimal help. Help the team make baby steps. Remember that when people panic, they go back to their old habits, even though those habits didn’t work. Focus on tiny positive increments.

Let Them Feel Pain

Sometimes you just have to watch the train wreck. If your suggestions for improvement were rebuffed, and the team fails, bring your suggestion up again and ask the team to consider trying it for a few iterations. People are most willing to change in the areas where they feel the most pain.

Build Your Credibility

You might now be working with programmers who haven’t worked closely with testers before. Show them how you can help. Go to them with issues you’ve found rather than opening bug reports. Ask them to review code with you before they check it in. When they realize you’re contributing real value, they’re more likely to listen to your ideas.

Work On Your Own Professional Development

Read books and articles, go to user group meetings and conferences, and learn a new tool or scripting language. Start learning the language your application is coded in, and ask the programmers on your team if you can pair with them or if they’ll tutor you. Your coworkers will respect your desire to improve your skills. If your local user group is willing to listen to your presentation on agile testing, or a software newsletter publishes your automation article, your teammates might notice you have something worth hearing too.