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:
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:
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.