The Release


Let's talk about releases. As we approach the downhill drive of each iteration's end, we seem to hit more and more unexpected curves and potholes in the form of defects. An imminent release date is sure to produce some tangled, hard-to-reproduce, ugly bug blocking our way. Evidently we, and the customer, become a lot more cunning in our testing as these milestones approach, and we find defects we somehow missed before.

As we discussed in Chapter 26, you should have spent time preparing your customer for these situations. Anxiety over deadlines makes problems seem bigger. If customers understand the process for dealing with defects, they'll react more calmly if defects are found. The best you can do is continue to log defects and get an estimate for fixing each one. Discuss these with the customer every day. Let her prioritize and decide what she can and can't live with. Remind her that fixing defects at this late date will require extensive retesting and runs the risk of introducing new bugs. That's a concept everyone understands.

This is the time you really have to walk a fine line. Make sure the customer gets what she's paid for. The acceptance test results will show if she did. In XP projects, as in any other software projects, customers often ask for just one more teeny added bit of functionality that wasn't in the stories you started the iteration with. Unless your team has finished all the stories originally chosen, don't let them be tempted to squeeze in more work. Our experience is that programmers are a lot more susceptible to these types of requests than testers are. Of course, your manager or coach should manage this sort of thing, but if he doesn't, do what you can to keep the team on track.

Your team will come through on the absolute necessities. The rest can be included as stories in the next iteration and release. We've lived through some hair-raising releases, but most problems were due to basic problems like development and test environments that didn't match production (yes, this is a mortal sin in the QA world, but Lisa has worked on projects where this was beyond her team's control, and that could happen to you too).

Having scared you with these worst-case scenarios, we should now say that if your team has done their best to use XP practices, you're probably in for a pleasant surprise. Some of the pleasantest production launches we've enjoyed have been in XP projects. Read on for an example of the advantages of XP from a quality perspective.



Testing Extreme Programming
Testing Extreme Programming
ISBN: 0321113551
EAN: 2147483647
Year: 2005
Pages: 238

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net