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

Version-control automated tests along with the production code that they verify.

Good test management ensures that tests can provide effective documentation of the system and of development progress.

Get started on test automation today.

Part V An Iteration in the Life of a Tester

Whenever we do tutorials, webinars, or Q&A sessions with participants who are relatively new to agile development, we’re always asked questions such as “What do testers do during the first part of an iteration before anything’s ready to test?” or “Where does user acceptance testing fit into an agile release cycle?” It’s easy to expound on theories of who should do what and when, in an agile process, but we find giving concrete examples from our own experience is the best help we can give agile newbies. Through our talking to many different agile teams, we’ve learned that there’s a lot of commonality in what works well for agile development and testing.

In this part of the book, we’ll follow an agile tester’s life throughout an iteration. Actually, we’ll explore more than just an iteration. We’ll start with what testers do during release or theme planning, when the team looks at the work it will do for several upcoming iterations. We’ll give examples of what testers can do to help the team members hit the ground running when they start the iteration. We’ll show how coding and testing are part of one integrated process of delivering software, and we’ll describe how testers and programmers work closely and incrementally. We’ll explain different ways that testers can help their teams stay on track and gauge progress, including useful approaches to metrics and handling defects. We’ll look at testing-related activities involved in wrapping up an iteration and finding ways to improve for the next one. Finally, we’ll examine a tester’s role in a successful release, including the end game, UAT, packaging, documentation, and training.

The activities described in this slice-of-life look at agile testing can be performed by anyone on the team, not only testing specialists. On some teams, all team members can, and do, perform any task, be it development, testing, database, infrastructure, or other tasks. For simplicity, in this section we’ll assume we’re following someone whose primary role is testing as they help to deliver high-quality software.

Chapter 15 Tester Activities in Release or Theme Planning

Agile development teams complete stories and deliver production-ready software in every iteration but plan the big picture or a larger chunk of functionality in advance. A theme, epic, or project may encompass several iterations. In this chapter, we look at what testers do when their team takes time to plan their release. We also consider ways to track whether our development is proceeding as anticipated, or if course corrections are needed.

The Purpose of Release Planning

One reason software teams try agile development is because they know long-range plans don’t work. Most business environments are volatile, and priorities change every week, or even every day. Agile development is supposed to avoid “big design up front.” Most of us have experienced making plans that turned out to be a waste of effort. But we have to have some understanding of what our customer is looking for and how we might deliver it in order to get off to a good start. Fortunately, an agile approach can make planning a useful way to give us a head start on knowing how we will deliver the product.

Agile Planning Applied

Janet’s sister, Carol Vaage, teaches first grade when she isn’t directing conferences. She relates her first experience with using agile practices to organize a conference:

My table is loaded with binders and to-do lists, and a feeling of being overwhelmed freezes me into inaction. I am Conference Director and the task right now seems onerous. When my sister offers to help me, I agree, because I am desperate to get this planning under control. I welcome Janet to my clutter, show her my pages of hand-written lists of things that need to get done, explain the huge tasks waiting for my attention, and share how my committee works.

Janet showed me in simple language how to separate each task onto a sticky note and use color coordination for different responsibilities and different individuals. She explained about the columns of “To Do,” “In Progress,” “To Review,” and “Done.” I had never heard of the word iteration before but fully understood about a timeline. She recommended two-week blocks of time, but I chose one-week iterations. We set up a wall for my planning board, and Janet left me to pull it together and to add the tasks needed.

In the six days since Janet has been here, ten tasks have been moved from the To-Do column to In-Progress. Three tasks are Done, and specific time-related tasks have been blocked by the correct time period. The most positive thing is that as I add more tasks in the To-Do column, I am not feeling overwhelmed. I understand that all I need to do is initiate the steps to start it, and then the job becomes easier. The feeling of chaos is gone; I see progress and understand that there is still much work to be done. The timeline is clear, the tasks are discrete and concrete. And the most difficult task of all, finding a way to coordinate the video conference for our keynote speaker has been tackled. This system works!

Agile planning and tracking practices are useful for more than software development. A little time carefully invested, and simple tools used in organizing and planning the testing activities and resources for a release, will help the team deliver high-quality software.

XP teams may take a day every few months for release planning. Other agile teams do advance planning when getting ready to start on a theme, epic, or major feature, which we think of as a related group of stories. They work to understand the theme or release at a high level. What is the customer’s vision of what we should be delivering? What’s the purpose of the release? What’s the big picture? What value will it deliver to the business, to the customers? What other teams or projects are involved and require coordination? When will UAT take place? When will code be released to staging, to production? What metrics do we need to know if we’re on track? These general questions are addressed in release planning.

Some teams don’t spend much time doing release planning activities. Priorities change quickly, even within a particular theme of features. Nobody wants to do too much work up front that ends up being wasted. Some teams just look at the first couple of stories to make sure they can get a running start. At the very least, teams want to know enough to get their system architecture pointed in the right direction and get started on the first few stories.

These planning meetings aren’t intended to plan every iteration of the release in detail. And we know we can’t predict exactly how many stories we can complete each iteration. However, we do have an idea of our average velocity, so we can get a general idea of the possible scope of the release. The team talks about the features and stories, trying to get a 20,000-foot view of what can go into the release and how many iterations it might take to complete. Both of us like Mike Cohn’s approach to release planning in his book Agile Estimating and Planning [2005]. Stories that the business wants to include are sized relative to each other, and then features are prioritized according to the value they deliver. The team may identify “thin slices” through the features to determine what stories absolutely have to be done, what’s in scope, what “nice-to-haves” could be put off until later. They look at dependencies between stories, relative risk, and other factors that determine the order in which features should be coded. The order in which stories are coded is as important, or sometimes more important, than the size of the stories. Teams want to deliver value the first iteration of the release.