Everyone on an agile team is a tester. Anyone can pick up testing tasks. If that’s true, then what is special about an agile tester? If I define myself as a tester on an agile team, what does that really mean? Do agile testers need different skill sets than testers on traditional teams? What guides them in their daily activities?
In this article, excerpted from the book, 'Agile Testing: A Practical Guide for Testers and Agile Teams,' authors Lisa Crispin and Janet Gregory talk about the agile testing mind-set, show how agile values and principles guide testing, and give an overview of how testers add value on agile teams.
By Lisa Crispin and Janet Gregory
We define an agile tester this way: a professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development. Agile testers tend to have good technical skills, know how to collaborate with others to automate tests, and are also experienced exploratory testers. They’re willing to learn what customers do so that they can better understand the customers’ software requirements.
Who’s an agile tester? She’s a team member who drives agile testing. We know many agile testers who started out in some other specialization. A developer becomes test-infected and branches out beyond unit testing. An exploratory tester, accustomed to working in an agile manner, is attracted to the idea of an agile team. Professionals in other roles, such as business or functional analysts, might share the same traits and do much of the same work.
Skills are important, but attitude counts more. Janet likes to say, “Without the attitude, the skill is nothing.” Having had to hire numerous testers for our agile teams, we've put a lot of thought into this and discussed it with others in the agile community. Testers tend to see the big picture. They look at the application more from a user or customer point of view, which means they’re generally customer-focused.
What makes a team “agile”? To us, an agile team is one that continually focuses on doing its best work and delivering the best possible product. In our experience, this involves a ton of discipline, learning, time, experimentation, and working together. It’s not for everyone, but it’s ideal for those of us who like the team dynamic and focus on continual improvement.
Successful projects are a result of good people allowed to do good work. The characteristics that make someone succeed as a tester on an agile team are probably the same characteristics that make a highly valued tester on any team.
An agile tester doesn’t see herself as a quality police officer, protecting her customers from inadequate code. She’s ready to gather and share information, to work with the customer or product owner in order to help them express their requirements adequately so that they can get the features they need, and to provide feedback on project progress to everyone.
Agile testers, and maybe any tester with the right skills and mind-set, are continually looking for ways the team can do a better job of producing high-quality software. On a personal level, that might mean attending local user group meetings or roundtables to find out what other teams are doing. It also means trying out new tools to help the team do a better job of specifying, executing, and automating customer requirements as tests.
The bottom line is that agile testers, like their agile teammates, enjoy learning new skills and taking on new challenges, and they don’t limit themselves to solving only testing issues. This isn’t just a trait of testers; we see it in all agile team members. Agile testers help the developer and customer teams address any kind of issue that might arise. Testers can provide information that helps the team look back and learn what’s working and what isn’t.
Creativity, openness to ideas, willingness to take on any task or role, focus on the customer, and a constant view of the big picture are just some components of the agile testing mind-set. Good testers have an instinct and understanding for where and how software might fail, and how to track down failures.
Testers might have special expertise and experience in testing, but a good agile tester isn’t afraid to jump into a design discussion with suggestions that will help testability or create a more elegant solution. An agile testing mind-set is one that is results-oriented, craftsman-like, collaborative, eager to learn, and passionate about delivering business value in a timely manner.
Individuals can have a big impact on a project’s success. We’d expect a team with more experienced and higher-skilled members to outperform a less talented team. But a team is more than just its individual members. Agile values and principles promote a focus on the people involved in a project and how they interact and communicate. A team that guides itself with agile values and principles will have higher team morale and better velocity than a poorly functioning team of talented individuals.
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
What do these principles bring to the team? Together, they bring business value. In agile development, the whole team takes responsibility for delivering high-quality software that delights customers and makes the business more profitable. This, in turn, brings new advantages for the business.
Team members wear many hats, and agile development tends to avoid classifying people by specialty. Even with short iterations and frequent releases, it’s easy to develop a gap between what the customer team expects and what the team delivers. Using tests to drive development helps to prevent this, but you still need the right tests.
Agile testers not only think about the system from the viewpoint of stakeholders who will live with the solution but they also have a grasp of technical constraints and implementation details that face the development team. Programmers focus on making things work. If they’re coding to the right requirements, customers will be happy. Unfortunately, customers aren’t generally good at articulating their requirements. Driving development with the wrong tests won’t deliver the desired outcome. Agile testers ask questions of both customers and developers early and often, and help shape the answers into the right tests.
Agile testers take a much more integrated, team-oriented approach than testers on traditional waterfall projects. They adapt their skills and experience to the team and project. A tester who views programmers as adversaries, or sits and waits for work to come to her, or expects to spend more time planning than doing, is likely to cling to skills she learned on traditional projects and won’t last long on an agile team.
Peril: You’re Not “Really” Part of the Team
If you’re a tester, and you’re not invited to attend planning sessions, stand-ups, or design meetings, you might be in a situation where testers are viewed as somehow apart from the development team. If you are invited to these meetings but you’re not speaking up, then you’re probably creating a perception that you aren’t really part of the team. If business experts are writing stories and defining requirements all by themselves, you aren’t participating as a tester who’s a member of an agile team.
If this is your situation, your team is at risk. Hidden assumptions are likely to go undetected until late in the release cycle. Ripple effects of a story on other parts of the system aren’t identified until it’s too late. The team isn’t making the best use of every team member’s skills, so it’s not going to be able to produce the best possible software. Communication might break down, and it’ll be hard to keep up with what the programmers and customers are doing. The team risks being divided in an unhealthy way between developers and testers, and there’s more potential that the development team will become isolated from the customer team.
How can you avoid this peril? See if you can arrange to be located near the developers. If you can’t, at least come to their area to talk and pair test. Ask them to show you what they’re working on. Ask them to look at the test cases you’ve written. Invite yourself to meetings if nobody else has invited you. Make yourself useful by testing and providing feedback, and become a necessity to the team.
Help customers develop their stories and acceptance tests. Push the “whole team” attitude, and ask the team to work on testing problems. If your team is having trouble adapting to agile development, suggest experimenting with some new ideas for an iteration or two. Propose adopting the “Power of Three” rule to promote good communication. Use the information in this book to show that testers can help agile teams succeed beyond their wildest expectations.
During story estimating and planning sessions, agile testers look at each feature from multiple perspectives: business, end user, production support, and programmer. They consider the problems faced by the business and how the software might address them. They raise questions that flush out assumptions made by the customer and developer teams. At the start of each iteration, they help to make sure the customer provides clear requirements and examples, and they help the development team turn those into tests. The tests drive development, and test results provide feedback on the team’s progress. Testers help to raise issues so that no testing is overlooked; it’s more than functional testing. Customers don’t always know that they should mention their performance and reliability needs or security concerns, but testers think to ask about those. Testers also keep the testing approach and tools as simple and lightweight as possible. By the end of the iteration, testers verify that the minimum testing was completed.
Lines between roles on an agile team are blurred. Other team members might be skilled at the same activities that testers perform. For example, analysts and programmers also write business-facing tests. As long as all testing activities are performed, an agile team doesn’t necessarily require members who identify themselves primarily as testers. However, we have found that teams benefit from the skills that professional testers have developed. The agile principles and values we’ve discussed will help any team do a good job of testing and delivering value.
In this chapter, we covered principles for agile testers and the values we think an agile tester needs to possess in order to contribute effectively to an agile team.
This excerpt is from the book,
‘Agile Testing: A Practical Guide for Testers and Agile Teams’, authored by Lisa Crispin and Janet Gregory, published by Pearson/Addison-Wesley Professional, ISBN 0321534468, Jan. 2009, Copyright 2009 Pearson Education, Inc. For a full table of contents please visit the publisher site: