Agile Testing: A Practical Guide for Testers and Agile Teams

Chapter 4 Team Logistics

Agile teams stress that face-to-face communication is critical to the success of a project. They also encourage using the “whole-team” approach. What does this mean to the testers? This chapter talks about some of the issues involving team structure and physical logistics. There’s more to creating a cohesive team than just moving chairs and desks.

Team Structure

Having separate functional groups can make life difficult for agile teams. Constant communication is critical. Team members need to work closely with one another, whether the work is done virtually or in the same physical location.

We use the terms “QA team” and “test team” interchangeably here. It can be argued whether “QA teams” are really doing quality assurance or not, but the term has become a common one attached to test teams, so we use it too.

Independent QA Teams

Many organizations, both large and small, think it is important to have an independent QA or test team in order to get an honest opinion about the quality of a product. We’re often asked the questions, “Is there a place for a test organization in the whole-team approach?” and “If so, what is its role?”

Some of the reasons we’re given for wanting to keep the QA team separate from the development team are:

It is important to have that independent check and audit role.

The team can provide an unbiased and outside view relating to the quality of the product.

If testers work too closely with developers, they will start to think like developers and lose their customer viewpoint.

If the testers and developers report to the same person, there is a danger that the priority becomes delivering any code rather than delivering tested code.

Teams often confuse “independent” with “separate.” If the reporting structure, budgets, and processes are kept in discrete functional areas, a division between the programmers and testers is inevitable. This can lead to friction, competition, and an “us versus them” attitude. Time is wasted on duplicate meetings, programmers and testers don’t share a common goal, and information sharing is nonexistent.

There are reasons for having a QA manager and an independent test team. However, we suggest changing the reasons as well as the structure. Rather than keeping the testers separate as an independent team to test the application after coding, think about the team as a community of testers. Provide a learning organization to help your testers with career development and a place to share ideas and help each other. If the QA manager becomes a practice leader in the organization, that person will be able to teach the skills that testers need to become stronger and better able to cope with the ever-changing environment.

We don’t believe that integrating the testers with the project teams prevents testers from doing their jobs well. In fact, testers on agile teams feel very strongly about their role as customer advocate and also feel they can influence the rest of the team in quality thinking.

Integration of Testers into an Agile Project

The whole-team approach in agile development has provoked many organizations that have adopted agile development to disband their independent QA teams and send their testers to work with the project groups. While this sounds great, some organizations have found that it doesn’t work as expected. More than one organization has had most, if not all, of their testers quit when they found themselves on an agile development team with no idea what they should be doing.

Developers get training on pair programming, test-driven development, and other agile practices, while testers often seem to get no training at all. Many organizations fail to recognize that testers also need training on pair testing, working with incomplete and changing requirements, automation, and all of the other new skills that are required. It’s critical that testers receive training and coaching so that they can acquire the skills and understanding that will help them succeed, such as how to work with customers to write business-facing tests. Programmers also might need coaching to understand the importance of business-facing tests and the whole-team approach to writing and automating tests.

Janet has helped integrate several independent test teams into agile projects. She finds that it can take up to six months for most testers to start feeling confident about working with the new process.

The pairing of programmers and testers can only improve communication about the quality of the product. Developers often need to observe the behavior of the application on the tester’s workstation if that behavior can’t be reproduced in the development environment. Testers can sometimes sit down with the developer to reproduce a problem more easily and quickly than they can by trying to record the steps in a defect. This interaction reduces the time spent on non-oral communication.

Comments we’ve heard from testers on this subject include the following:

“Being closer to the development of the product makes me a better tester.”

“Going to lunch with developers builds a better team, one that wants and likes to work together.”

One major advantage of an integrated project team is that there’s only one budget and one schedule. There is no “testing” time to cut if all of the functionality is not finished. If there is no time to test a new feature, then there is no time to develop it in the first place. The whole-team approach to taking responsibility for quality is very powerful, as we point out throughout this book.

Lisa’s Story

I once joined an XP team that had been depending solely on unit-level testing and had never had anyone in a tester role before. Their customer wasn’t all that happy with the results, so they decided to hire a tester. While I attended daily stand-ups, I wasn’t allowed to talk about testing tasks. Testing time wasn’t included in story estimates, and testing tasks weren’t part of iteration planning. Stories were marked “done” as soon as coding tasks were complete.

After the team missed the release date, which was planned for after three two-week iterations, I asked the team’s coach to try the whole-team approach to testing. Testing tasks went up on the board along with coding tasks. Stories were no longer considered done until testing tasks were finished. Programmers took on testing tasks, and I was a full participant in daily stand-ups. The team had no more issues meeting the release plans they set.

—Lisa

Testers need to be full-fledged members of the development team, and testing tasks need to be given the same attention as other tasks. Again, the whole-team approach to testing goes a long way toward ensuring that testing tasks are completed by the end of each iteration and release. Be sure to use retrospectives to evaluate what testers need to integrate with their new agile team and what skills they might need to acquire. For example, testers might need more support from programmers, or from someone who’s an expert in a particular type of testing.

A smart approach to planning the organizational changes for agile development makes all the difference to a successful transition. Ask the QA and development managers to figure out their own roles in the new agile organization. Let them plan how they will help their testers and developers be productive on the new agile teams. Provide training in agile practices that the team doesn’t know. Make sure all of the teams can communicate with each other. Provide a framework that lets each team learn as it goes, and the teams will find a way to succeed.

Transitioning QA and Engineering Teams—Case Study

Christophe Louvion is a CTO and agile coach for high-profile Internet companies. He told us about one experience he had while helping his company implement agile development. As the agile coach, he wanted to truly implement agile development and avoid the common “small waterfall” mistake, where the developers spend a week writing code and the testers spend the next week testing it.

His company at the time was an organization of about 120 engineers, including the internal IT departments. Before transitioning to Scrum, the company was organized functionally. There were directors of QA and Engineering, and the idea of product-based teams was hard for management to accept. The managers of these teams struggled with the following question: “What is my job now?” Christophe turned this around on the managers and said: “You tell me.”

He worked with the Engineering and QA managers to help them figure out what their jobs would be in the new agile environment. Only when they were able to speak with one voice did they all go to the teams and explain their findings.

In the new agile organization, managers deal with specific domain knowledge, resources, prioritization, and problems that arise. The Engineering and QA managers work hand-in-hand on a daily basis to resolve these types of issues. Christophe and the two managers looked at what prevented testers from being productive in the first week of the two-week iteration and taught them how to help with design.

For the programmers, the question was “How do I make it so that the code is easy to test?” The engineers weren’t trained in continuous integration, because they were used to working in phased cycles. They needed lots of training in test-driven design, continuous integration, and other practices. Their managers ensured that they got this training.

Configuration management (CM) experts were brought in to help with the build process. The CM team is separate from Engineering and QA at the company, and it provides the framework for everything in the build process, including database objects, hardware, and configurations. Once the build process framework was implemented, integrating coding and testing was much easier to talk about.

Having management figure out their new roles first, and then getting a build process framework in place with everything in source code control, were key to the successful transition to agile. Another success factor was having representatives from all teams—Engineering, QA, the CM, network, and the system administrator groups and product teams—participate in daily stand-ups and planning activities. This way, when testing issues came up, they could be addressed by everyone who could help. As Christophe says, their approach integrates everyone and puts a focus on testing.

See the bibliography for a link to some of Christophe’s writings on managing agile teams.

Agile Project Teams

Agile project teams are generally considered cross-functional, because each team has members from many different backgrounds. The difference between a traditional cross-functional team and an agile team is the approach to the whole-team effort. Members are not just “representing” their functions in the team but are becoming true members of the team for as long as the project or permanent team exists (see Figure 4-1).

Figure 4-1 Traditional functional teams structure vs. agile team structure

Because projects vary in size, project teams might vary in structure. Organizations with large projects or many projects that happen simultaneously are having success using a matrix-type structure. People from different functional areas combine to form a virtual team while still reporting back to their individual organizational structures. In a large organization, a pool of testers might move from project to project. Some specialists, such as security or performance testers, might be shared among several teams. If you’re starting up a project, identify all of the resources the project will need. Determine the number of testers required and the skill set needed before you start. The testers start with the team and keep working until the project is complete, and at that time they go on to the next project.

While testers are part of the team, their day-to-day work is managed the same as the rest of the project team’s work. A tester can bounce new ideas off of the larger tester community, which includes testers on different project teams across a large organization. All testers can share knowledge and ideas. In organizations that practice performance reviews, the QA manager (if there is one) might drive the reviews and get input from the project team.

As with any new team, it takes a while for a team to jell. If the length of the project is short and the teams are constantly changing, the organization needs to be aware that the first iteration or two of every project will include the new team members getting used to working with each other. Refactor your organization as needed, and remember to include your customers. The best teams are those that have learned to work together and have developed trust with one another.

Physical Logistics

Many organizations that are thinking of adopting agile try to create project teams without co-locating the team in an open-plan environment. To support agile values and principles, teams work better when they have ready access to all team members, easy visibility of all project progress charts, and an environment that fosters communication.

Testers and customers sitting close to the programmers enable the necessary communalization. If logistics prohibit co-location, teams can be inventive.

Janet’s Story

I worked in a team where space prevented all team members from sitting together. The programmers had an area where they could pair-program with ease, but the testers and the customer were seated in another area. At first, it was the testers that made the trip to the storyboard area where the programmers sat to participate in stand-ups and whenever they had a question for one of the programmers. Few of the programmers made the trip (about 50 feet) to the testers’ area. I started keeping a candy dish handy with treats and encouraged the developers to take some as often as they wanted. But there was one rule—they needed to ask a question of one of the testers if they came for candy. Over time, the walk got shorter for all team members. No one side was doing all of the walking, and communication flourished.

—Janet

Team size offers different types of challenges to the organization. Small teams mean small areas, so it is usually easier to co-locate members. Large teams might be spread globally, and virtual communication tools are needed. Co-locating large teams usually means renovating existing space, which some organizations are reluctant to do. Understand your constraints, and try to find solutions to the problems your team encounters rather than just accepting things as “the way it is.”

Janet’s Story

One team I worked on started in one corner of the floor, but expanded over the course of three years, gradually taking over 70% of the floor. Walls were taken down, offices removed, and large open areas created. The open areas and pods of teams worked well, but all the open space meant wall space was lost. Windows became story boards and whiteboards, and rolling whiteboards were ordered that could be used as teams needed them.

—Janet

Co-located teams don’t always live in a perfect world, and distributed teams have a another set of challenges. Distributed teams need technology to help them communicate and collaborate. Teleconferencing, video conferencing, webcams, and instant messaging are some tools that can promote real-time collaboration for teams in multiple locations.

Whether teams are co-located or distributed, the same questions usually come up about what resources are needed on an agile team and how to obtain them. We’ll discuss these in the next section.

Resources

New agile team members and their managers have lots of questions about the makeup of the team. Can we use the same testers that we had with our traditional projects, or do we need to hire a different type of tester? How many testers will we need? Do we need people with other specialized skills? In this section, we talk a little about these questions.

Tester-Developer Ratio

There have been many discussions about the “right” ratio of the number of testers to the number of developers. This ratio has been used by organizations to determine how many testers are needed for a project so that they can hire accordingly. As with traditional projects, there is no “right” ratio, and each project needs to be evaluated on its own. The number of testers needed will vary and depends upon the complexity of the application, the skill set of the testers, and the tools used.

We have worked on teams with a tester-developer ratio of anywhere from 1:20 to 1:1. Here are a couple of our experiences.

Janet’s Story

I worked on a project with a 1:10 ratio that developed a message-handling system. There was very little GUI, and I manually tested that part of the application, looking at usability and how well it matched the customer’s expectations. The programmers did all of the automated regression testing while I worked with them to validate the effectiveness of the test cases written. I pair-tested stories with the developers, including load testing specific stories.

I never felt that I didn’t have enough time to do the testing I needed to, because the developers believed that quality was the whole team’s responsibility.

—Janet

Lisa’s Story

I was once the only professional tester on a team of up to 20 programmers developing a content management system on an Internet shopping website. The team began to get really productive when the programmers took on responsibility for both manual testing and test automation. One or two programmers wore a “tester hat” for each iteration, writing customer-facing tests ahead of coding and performing manual tests. Additional programmers picked up the test automation tasks during the iteration.

Conversely, my current team has had two testers for every three to five programmers. The web-based financial application we produce has highly complex business logic, is high risk, and test intensive. Testing tasks often add up to the same amount of time as programming tasks. Even with a relatively high tester–programmer ratio, programmers do much of the functional test automation and sometimes pick up manual testing tasks. Specialized testing tasks such as writing high-level test cases and detailed customer-facing tests are usually done by the testers.

—Lisa

Rather than focus on a ratio, teams should evaluate the testing skills they need and find the appropriate resources. A team that takes responsibility for testing can continually evaluate whether it has the expertise and bandwidth it needs. Use retrospectives to identify whether there’s a problem that hiring more testers would solve.

Hiring an Agile Tester

As we discussed in Chapter 2, “Ten Principles for Agile Testers,” there are certain qualities that make a tester suited to working on an agile team. We don’t want to go into a lot of detail about what kind of tester to hire, because every team’s need is different. However, we do believe that attitude is an important factor. Here’s a story of how Lisa’s team struggled to hire a new agile tester.

Lisa’s Story

Our first attempt at recruiting another tester was not very successful. The first job posting elicited many responses, and we interviewed three candidates without finding a good fit. The programmers wanted someone “techie,” but we also needed someone with the skills to collaborate with business people and help them to produce examples and requirements. We struggled to determine the content of the job posting in order to attract candidates with the right attitude and mind-set.

After soliciting opinions and suggestions from Janet and other colleagues in the agile testing community, we decided to look for a tester with the mind-set that is described in Chapter 2. We changed the job posting to include items such as these:

• Experience writing black box and GUI test cases, designing tests to mitigate risks, and helping business experts define requirements

• Experience writing simple SQL queries and insert/update statements and basic grasp of Oracle or another relational database

• At least one year of experience with some scripting or programming language and/or open source test tools

• Ability to use basic Unix commands

• Experience collaborating with programmers and business experts

• Experience in context-based, exploratory, or scenario testing a plus

• Ability to work as part of a self-organizing team in which you determine your tasks on a daily basis in coordination with coworkers rather than waiting for work to be assigned to you

These requirements brought candidates more suited to an agile testing job. I proceeded carefully with screening, ruling out people with a “quality police” mentality. Testers who pursued professional development and showed interest in agile development were more likely to have the right mind-set. The team needed someone who would be strong in the area of test tools and automation, so a passion for learning was paramount.

This more creative approach to recruiting a tester paid off. At that time, it wasn’t easy to find good “agile tester” candidates, but subsequent searches went more smoothly. We found that posting the tester position in less obvious places, such as a Ruby mailing list or the local agile user group, helped reach a wider range of suitable candidates.

Hiring an agile tester taught me a lot about the agile testing mind-set. There are testers with very good skill sets who would be valuable to any traditional test team but would not be a good fit on an agile team because of their attitude toward testing.

—Lisa

We need to consider more than just the roles that testers and programmers perform on the team. No matter what role you’re trying to fill, the most important consideration is how that person will fit on your team. With the agile whole-team approach, specialists on the team might be asked to step outside their areas of expertise and pitch in on other activities. Each team member needs to have a strong focus on quality and delivering business value. Consider more than just technical skills when you’re expanding your team.

Building a Team

We’ve talked a lot about the whole-team approach. But changes like that don’t just happen. We get asked questions like, “How do we get the team to jell?” or “How do we promote the whole-team approach?” One of the big ones is: “How do we keep everyone motivated and focused on the goal of delivering business value?”

Self-Organizing Team

In our experience, teams make the best progress when they’re empowered to identify and solve their own problems. If you’re a manager, resist the temptation to impose all your good ideas on the team. There are problems, such as personnel issues, that are best solved by managers, and there are times a coach needs to provide strong encouragement and lead the team when it needs leadership. It takes time for a new agile team to learn how to prioritize and solve its problems, but it’s okay for the team to make mistakes and stumble a few times. We think a high-functioning team has to grow itself. If you’re a tester, you’re in a good position to help the team figure out ways to get fast feedback, use practices such as retrospectives to prioritize and address issues, and find the techniques that help your team produce better software.

Involving Other Teams

You might need to get other teams on board to help your team succeed. Set up meetings; find ways to communicate as much as possible. Use a Scrum of Scrums to keep multiple teams coordinated, or just get involved with the other teams. If you have to bring in an expert to help with security testing, pair with that expert and learn as much as you can, and help them learn about your project.

If teams are scattered in different locations and time zones, figure out how to get as much direct communication as possible. Maybe representatives from each team can adjust their hours once or twice a week so that they can teleconference once a week. Make a phone call instead of sending an email whenever possible. Lisa’s team adjusted its planning meeting times to include a remote team member who works late at night. They schedule meetings for a time where his day overlaps with the rest of the team’s day.

Chapter 9, “Toolkit for Business-Facing Tests that Support the Team,” gives examples of tools that help remote teams collaborate.

Every Team Member Has Equal Value

Every team member has equal value to the team. If testers or any other team members feel left out or less valued, the whole-team approach is doomed. Make sure testers are invited to all meetings. If you’re a tester and someone forgets to invite you to a meeting, invite yourself. Nontechnical testers might think they’ll be out of place or overwhelmed at a design meeting, but sometimes they ask good questions that the techies didn’t think of.

Testers have a right to ask for and get help. If you’re a tester stuck on an automation problem, have the courage to ask a team member for help. That person might be busy right now, but he or she must commit to helping you in a reasonable amount of time. If you’re a manager or leader on your team, make sure this is happening, and raise the issue to the team if it’s not.

Performance and Rewards

Measuring and rating performance on an individual basis risks undermining team collaboration. We don’t want a programmer to feel she shouldn’t take on a testing task because she’s rated on delivering production code. We don’t want a system administrator to be so busy making sure her individual goals are met that she can’t help with a test environment problem.

Conversely, a good performer who was trying to work well with the team shouldn’t be knocked because the rest of the team didn’t pull together. This is a time when a manager needs to step up and help the team find its way. If major bugs made it to production, nobody should blame the testers. Instead, the whole team should analyze what happened and start taking steps to prevent a recurrence.

The development team needs to keep the business needs in mind. Set goals that serve the business, increase profitability, and make the customers happier. Work closely with the business so that your successes help the whole company succeed.

As we mentioned in Chapter 3, “Cultural Challenges,” celebrate every success, however small. A celebration might be a high-five, a company-provided lunch, or maybe just leaving work early to socialize a bit. The ScrumMaster on Lisa’s team hands out gold stars at stand-up meetings for special accomplishments. Acknowledge the people who help you and your team.

Teams can find novel ways to recognize each other’s contributions. Iteration review and demonstration meetings, where both the development team and customer team are present, are a good setting for recognizing both individual and team achievements.

Read about the “Shout-Out Shoebox” idea in Chapter 19, “Wrap Up the Iteration.”

What Can You Do?

If you’re a new tester on an agile team, especially a new agile team, what can you do to help the team overcome organizational challenges and succeed? How can you fit in with the team and contribute your particular skills and experience?

Put the ten principles we described in Chapter 2 to work. Courage is especially important. Get up and go talk to people; ask how you can help. Reach out to team members and other teams with direct communication. Notice impediments and ask the team to help remove them.

Agile development works because it gets obstacles out of our path and lets us do our best work. We can feel proud and satisfied, individually and as a team. When we follow agile principles, we collaborate well, use feedback to help improve how we work, and always look for new and better ways to accomplish our goals. All this means we can continually improve the quality of our product.

Summary

In this chapter, we looked at ways to build a team and a structure for successful agile testing and development.

Consider the importance of team structure; while testers might need an independent mind-set, putting them on a separate team can be counterproductive.

Testers need access to a larger community of testers for learning and trying out new ideas. QA teams might be able to create this community within their organization.

It is important for the whole team to be located together, to foster collaboration; if the team is distributed, provide tools to promote communication.

Hire for attitude.

There is no right tester–developer ratio. The right answer is, “It depends on your situation.”

Teams need to self-organize, identify and find solutions to their own problems, and look for ways to improve. They can’t wait for someone to tell them what to do.

Management should reward performance in a way that promotes the team’s effort to deliver business value but not penalize good individual performance if the team is struggling.

Testers can use agile principles to improve their own skills and increase their value to the team. They need to be proactive and find ways that they can contribute.