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.
Pierre Veragren, an SQA Lead at iLevel by Weyerhaeuser, identified a quality we often see in agile teams ourselves: “AADD,” Agile Attention Deficit Disorder. Anything not learned quickly might be deemed useless. Agile team members look for return on investment, and if they don’t see it quickly, they move on. This isn’t a negative characteristic when you’re delivering production-ready software every two weeks or even more often.
Retrospectives are a key agile practice that lets the team use yesterday’s experience to do a better job tomorrow. Agile testers use this opportunity to raise testing-related issues and ask the team to brainstorm ways to address them. This is a way for the team to provide feedback to itself for continual improvement.
Lisa’s Story
Our team had used retrospectives to great benefit, but we felt we needed something new to help us focus on doing a better job. I suggested keeping an “impediment backlog” of items that were keeping us from being as productive as we’d like to be. The first thing I wrote in the impediment backlog was our test environment’s slow response time. Our system administrator scrounged a couple of bargain machines and turned them into new, faster servers for our test environments. Our DBA analyzed the test database performance, found that the one-disk system was the impediment, and our manager gave the go-ahead to install a RAID for better disk access. Soon we were able to deploy builds and conduct our exploratory testing much faster.
—Lisa
We’ll talk more about retrospectives and how they can help your team practice continuous improvement in Chapter 19, “Wrap Up the Iteration.”
Respond to Change
When we worked in a waterfall environment, we got used to saying, “Sorry, we can’t make this change now; the requirements are frozen. We’ll have to put that in the first patch release.” It was frustrating for customers because they realized that they didn’t do a great job on defining all their requirements up front.
In a two-week agile iteration, we might have to say, “OK, write a card for that and we’ll do it in the next iteration or next release,” but customers know they can get their change when they want it because they control the priority.
Responding to change is a key value for agile practitioners, but we’ve found that it’s one of the most difficult concepts for testers. Stability is what testers crave so that they can say, “I’ve tested that; it’s done.” Continuously changing requirements are a tester’s nightmare. However, as agile testers, we have to welcome change. On Wednesday, we might expect to start stories A and B and then C the next Friday. By Friday, the customer could have re-prioritized and now wants stories A, X, and Y. As long as we keep talking to the customer, we can handle changes like that because we are working at the same pace with the rest of team.