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

Brian Marick (2004) recommends that we use examples to develop this language. When Lisa’s team digresses into a philosophical discussion during a sprint planning meeting, Lisa asks the product owner for an example or usage scenario. Testers can encourage whiteboard discussions to work through more examples. These help the customers envision their requirements more clearly. They also help the developers to produce well-designed code to meet those requirements.

Face-to-face communication has no substitute. Agile development depends on constant collaboration. Like other agile team members, the people doing testing tasks will continually seek out customer and technical team members to discuss and collaborate. When an agile tester suspects a hidden assumption or a misunderstood requirement, she’ll get a customer and a developer talking about it. If people in a different building or continent need to talk, they look for creative ways to replace face-to-face, real-time conversations.

Have Courage

Courage is a core value in XP, and practices such as test automation and continuous integration allow the team to practice this value. The developers have the courage to make changes and refactor the code because they have the safety net of an automated regression suite. In this section, we talk about the emotional courage that is needed when transitioning to an agile team.

Have you worked in an organization where testers were stuck in their own silo, unable to talk to either business stakeholders or other members of the technical team? While you might jump at the chance to join a collaborative agile environment, you might feel uncomfortable having to go ask the customer for examples, or ask a programmer to help automate a test or bring up a roadblock during the daily stand-up.

When you first join an agile team, or when your current team firsts transitions to agile development, it’s normal to experience fear and have a list of questions that need to be answered. How in the world are we going to be able to complete testing tasks for each story in such a short time? How will testing “keep up” with development? How do you know how much testing is enough? Or maybe you’re a functional testing manager or a quality process manager and it’s not clear to you where that role fits on an agile team, and nobody has the answers. Agile testers need courage to find the answers to those questions, but there are other reasons as well for having courage.

We need courage to let ourselves fail, knowing that at least we’ll fail fast and be able to learn from that failure. After we’ve blown an iteration because we didn’t get a stable build, we’ll start thinking of ways to ensure it doesn’t happen again.

We need courage to allow others to make mistakes, because that’s the only way to learn the lesson.

Lisa’s Story

I worked on a project where the agile coach insisted that I be on a separate testing team (often a team of one!) whose work wasn’t included in the programmers’ tracking and velocity. I had to just go along and try this. After the release ran into trouble because testing wasn’t finished, I asked the coach if we could try things my way for an iteration or two. The whole-team approach worked much better. Each story was tested and “done” by the end of the iteration, and the customers were much happier with the results.

—Lisa

We need courage to ask for help, especially when the person who could provide that help looks pretty busy and stressed-out himself. Climbing out of your old silo and joining in a team responsibility for success or failure takes courage. Asking a question or pointing out what you think is a flaw requires courage, even in a team supported by agile values and principles. Don’t be afraid! Agile teams are open and generally accepting of new ideas.

Keep It Simple

Kent Beck’s Extreme Programming Explained advised us to do the simplest thing that could possibly work. That doesn’t mean the first thing you try will actually work, but it ought to be simple.

Agile testers and their teams are challenged to not only produce the simplest possible software implementation but to take a simple approach to ensuring that software meets the customer requirements. This doesn’t mean that the team shouldn’t take some time to analyze themes and stories and think through the appropriate architecture and design. It does mean that the team might need to push back to the business side of the team when their requirements might be a bit elaborate and a simpler solution will deliver the same value.

Some of us worked in software organizations where we, as testers and quality assurance staff, were asked to set quality standards. We believe this is backwards, because it’s up to the customer team to decide what level of quality they want to pay for. Testers and other team members should provide information to customers and help them consider all aspects of quality, including nonfunctional requirements such as performance and security. The ultimate decisions are up to the customer. The team can help the customer make good decisions by its taking a simple, step-by-step approach to its work. Agile testing means doing the simplest tests possible to verify that a piece of functionality exists or that the customer’s quality standard (e.g., performance) has been met.

Chapter 9, “Toolkit for Business-Facing Tests that Support the Team,” and Chapter 11, “Critiquing the Product Using Technology-Facing Tests,” give examples of test tools.

Simple doesn’t mean easy. For testers, it means testing “just enough” with the lightest-weight tools and techniques we can find that will do the job. Tools can be as simple as a spreadsheet or a checklist. We need to automate regression tests, but we should push them down to the lowest level possible in order to encourage fast feedback. Even simple smoke tests might be enough for business-facing test automation.

Exploratory testing can be used to learn about your application and ferret out hard-to-find bugs, but start with the basics, time-boxing side trips and evaluating how far to go with edge cases. Simplicity helps us keep our focus on risk, return on investment, and improving in the areas of greatest pain.

Part IV, “Test Automation,” explains how to build a “doable” test automation strategy.

Practice Continuous Improvement

Looking for ways to do a better job is part of an agile tester’s mind-set. Of course, the whole team should be thinking this way, because the central core of agile is that the team always tries to do better work. Testers participate in team retrospectives, evaluating what’s working well and what needs to be added or tweaked. Testers bring testing issues up for the whole team to address. Teams have achieved their greatest improvements in testing and all other areas through the use of process improvement practices such as retrospectives and impediment backlogs. Some improvement ideas might become task cards. For larger problems, teams focus on one or two issues at a time to make sure they solve the real problem and not just the symptom.

Agile testers and their teams are always on the lookout for tools, skills, or practices that might help them add more value or get a better return on the customer’s investment. The short iterations of agile development make it easier to try something new for a few iterations and see whether it’s worth adopting for the long term.

Learning new skills and growing professionally are important to agile testers. They take advantage of the many available free resources to improve their specialized skills, such as exploratory testing. They go to meetings and conferences, join mailing lists, and read articles, blogs, and books to get new ideas. They look for ways to automate (or get help from their coworkers to automate) mundane or repetitive tasks so they have more time to contribute their valuable expertise.