Chapter 31. Introducing XP to Your Organization: A Tester s Point of View

Chapter 31. Introducing XP to Your Organization: A Tester's Point of View

Does the road hazard survival kit provide enough equipment to help you bring XP into an organization for the first time? Change is hard. XP is hard to master. It requires an incredible amount of discipline and attention. However, we're willing to suffer a little pain in the short run to enjoy the benefits of XP in the long run.

Time for a disclaimer: we, the authors of this book, have not had the experience of working for a large corporation into which we introduced XP. What we have done are XP projects for small and large external customers who use traditional software development methodologies. We've helped implement XP in small organizations already committed to practicing XP. We've used other agile development methodologies in large corporations. So some of the things we suggest here are just our opinions of what would work we haven't tried them in all these scenarios.

We've worked with companies where we had the following situation, and we've talked to several testers who have had similar experiences: a corporation with a large software development organization decides to start using XP. The testing organization is currently separate from development. When the programmers release the code to testers, it usually takes about a month to go through the testing cycle. During this period, the code base is essentially frozen. Some releases have required several passes through the testing cycle before being launched to production.

Extreme Programming asks programmers to release code every two (or one or three) weeks. The code must correctly run acceptance tests, defined by the customer, before the end of each iteration. The testers are part of the XP development team.

We've heard of many cases where the testing/QA organization is wary of XP, worried it will cause important steps to be bypassed, resulting in potential disaster. The testers might also fret about their job security, since many XP publications talk about customers writing and running acceptance tests and programmers automating them and fail to talk about testers much at all.

How do you successfully roll XP out in a situation like this? Should you keep the separate test organization? Do you need independent testers and quality assurance staff? If your testers and programmers have never worked closely together, how do you get them to start?

Here's an additional scenario: an organization introducing XP has testers, but they're nontechnical testers, who manually perform user acceptance testing. Can these testers be integrated into an XP team?

What if the organization needs to hire new testers? With the fast pace of XP, how do the new testers get up to speed on the domain knowledge and understanding of the project?

In introducing XP, we believe many criteria must be considered when thinking about how to set up the test functions.

• Do the test environments available to the development team exactly mirror production, with all systems installed and running?

• Do the systems needing development require extensive load and performance testing?

• Are the existing test organization and/or senior management fearful that XP schedules won't provide time for adequate testing?

• Is a professional tester, with experience in test automation or programming, available for each development team?

• Is the development organization responsible for all parts of the system under development, or must you integrate code from external development teams? ?

• What experience do the programmers on the team have? Are they senior programmers, well versed in best practices, or cowboy hackers, or fresh out of school? Do they have experience writing unit tests or other kinds of tests? Have they tried to write unit tests before, only to give up because it took them too long and they had to crank out production code?

• Do your teams have strong leadership?

• Does the organization have a solid commitment to quality?