Читаем Agile Testing: A Practical Guide for Testers and Agile Teams полностью

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