XP Testing with Blended Practices
| If your project includes test phases after development for each release, you have the dilemma of needing testers during these additional test phases. At the same time, they need to be involved in the next release, which the programmers are already starting. Speaking from experience, trying to work on two or more releases at once is guaranteed to adversely impact the sanity of any tester and make her feel doomed to doing a mediocre job with all her various testing and quality assurance tasks. Here are a few of the key practices we've talked about that lead to successful XP projects:
As the tester, you remain involved with a release when it goes into additional test phases. At the same time, the team begins development on the next iteration. How can you help write the acceptance tests if you're coordinating a separate team testing the previous release? How can you work with the programmers on test automation when you have to put together test reports for a customer who can't let go of all the old waterfall practices? Even though the team is responsible for acceptance testing, you won't feel able to effectively perform your tester role in this situation. It's easy to say we should just convince the customer to trust XP and throw away the old process he's followed between development and release. Hard to do, though so let's say you're stuck with it for a few releases at least. We worked on a project where the schedule looked something like Table 31.1, requiring a large development team broken into subteams. The customer was an external corporation. Each release also included related software produced by other, non-XP teams. The ideal approach to solving this dilemma is to have one tester responsible for each release. Testers need to be intimately familiar with the functionality and technology of a project to test it effectively and shepherd it successfully into production. They also need to be intimately familiar with customer needs to be effective. You can't send Tester A out to do all the customer facing work and have Tester B do all the technical work with the development team. Neither tester will have all the information needed to be effective. By performing the complete tester role from start to finish of a release, you can maximize your value to the team.
To handle the schedule shown in Table 31.1, we'll have three different people in the tester role: Lisa, Joe, and Kay. Each release will have a primary tester responsible for the tester role from start to finish. All testers can help on all releases as they have time, but each release will have one devoted tester, and no tester gets stuck with two releases at once. The testers will still be responsible for releases that overlap, but the overlap is between a major release and a minor release rather than two major releases (see Table 31.2). Lisa, Kay, and Joe will each perform the full range of tester tasks and responsibilities, working with the programmers, customer, and the customer's own programmer and testing organizations.
You wouldn't have this problem in a self-contained XP team, which would continuously execute small iterations and release them to production without additional testing phases. XP "outside the box" requires adjustments like this one, and introducing XP into an existing development culture will also require these types of adjustments. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
EAN: 2147483647
Pages: 238