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

The four value statements in the Agile Manifesto, which we presented at the start of the first chapter, show preferences, not ultimatums, and make no statements about what to do or not to do. The Agile Manifesto also includes a list of principles that define how we approach software development. Our list of agile “testing” principles is partially derived from those principles. Because we both come from the Extreme Programming culture, we’ve adopted many of its values and underlying principles. We’ve also incorporated guidelines and principles that have worked for our teams. Your team’s own values and principles will guide you as you choose practices and make decisions about how you want to work.

The principles we think are important for an agile tester are:

Provide Continuous Feedback.

Deliver Value to the Customer.

Enable Face-to-Face Communication.

Have Courage.

Keep It Simple.

Practice Continuous Improvement.

Respond to Change.

Self-Organize.

Focus on People.

Enjoy.

Provide Continuous Feedback

Given that tests drive agile projects, it’s no surprise that feedback plays a big part in any agile team. The tester’s traditional role of “information provider” makes her inherently valuable to an agile team. One of the agile tester’s most important contributions is helping the product owner or customer articulate requirements for each story in the form of examples and tests. The tester then works together with teammates to turn those requirements into executable tests. Testers, programmers, and other team members work to run these tests early and often so they’re continually guided by meaningful feedback. We’ll spend a lot of time in this book explaining ways to do this.

When the team encounters obstacles, feedback is one way to help remove them. Did we deliver a user interface that didn’t quite meet customer expectations? Let’s write a task card reminding us to collaborate with the customer on paper prototypes of the next UI story.

Is management worried about how work is progressing? Display a big visible chart of tests written, run, and passing every day. Display big-picture functionality coverage such as test matrices. Having trouble getting the build stable? Lisa’s team displayed the number of days remaining until time to tag the build for release in order to keep everyone focused on finishing stories in time. After that became a habit, they didn’t need the visual cue anymore.

Deliver Value to the Customer

Agile development is about delivering value in small releases that provide exactly the functionality that the customer has most recently prioritized. This usually means limiting scope. It’s easy to get caught up in the customer team’s desire for cool features. Anyone can question these additions, but a tester often recognizes the impact to the story, because they need to think about the testing repercussions.

Lisa’s Story

Our product owner participates in planning meetings before each iteration. Nevertheless, after the iteration has started and we discuss more details about the stories and how to test them, he often brings up an idea that didn’t come out during the planning, such as, “Well, it would really be nice if the selection on this report could include X, Y, and Z and be sorted on A as well.” An innocent request can add a lot of complexity to a story. I often bring in one of the programmers to talk about whether this addition can be handled within the scope of the story we had planned. If not, we ask the product owner to write a card for the next iteration.

—Lisa

Agile testers stay focused on the big picture. We can deliver the most critical functionality in this iteration and add to it later. If we let new features creep in, we risk delivering nothing on time. If we get too caught up with edge cases and miss core functionality on the happy path, we won’t provide the value the business needs.

Lisa’s Story

To ensure that we deliver some value in each iteration, our team looks at each story to identify the “critical path” or “thin slice” of necessary functionality. We complete those tasks first and then go back and flesh out the rest of the features. The worst-case scenario is that only the core functionality gets released. That’s better than delivering nothing or something that works only halfway.

—Lisa

Agile testers take the same approach as that identified in Lisa’s story. While one of our skills is to identify test cases beyond the “happy path,” we still need to start by making sure the happy path works. We can automate tests for the happy path, and add negative and boundary tests later. Always consider what adds the most value to the customer, and understand your context. If an application is safety-critical, adding negative tests is absolutely required. The testing time needs to be considered during the estimation process to make sure that enough time is allotted in the iteration to deliver a “safe” feature.

Enable Face-to-Face Communication

No team works well without good communication. Today, when so many teams are distributed in multiple geographical locations, communication is even more vital and more of a challenge. The agile tester should look for unique ways to facilitate communication. It is a critical aspect to doing her job well.

Janet’s Story

When I was working with one team, we had a real problem with programmers talking with the product owner and leaving the testers out of the discussion. They often found out about changes after the fact. Part of the problem was that the developers were not sitting with the testers due to logistical problems. Another problem was history. The test team was new, and the product owner was used to going straight to the programmers.

I took the problem to the team, and we created a rule. We found great success with the “Power of Three.” This meant that all discussions about a feature needed a programmer, a tester, and the product owner. It was each person’s responsibility to make sure there was always a representative from each group. If someone saw two people talking, they had the right to butt into the conversation. It didn’t take very long before it was just routine and no one would consider leaving the tester out of a discussion. This worked for us because the team bought into the solution.

—Janet

Any time there is a question about how a feature should work or what an interface should look like, the tester can pull in a programmer and a business expert to talk about it. Testers should never get in the way of any direct customer-developer communication, but they can often help to make sure that communication happens.

Agile testers see each story or theme from the customer’s point of view but also understand technical aspects and limitations related to implementing features. They can help customers and developers achieve a common language. Business people and software people often speak different languages. They have to find some common ground in order to work together successfully. Testers can help them develop a shared language, a project dialect, or team jargon.