© 2000 Todd Berbert
Kent Beck is the author of Extreme Programming Explained: Embrace Change, and his book is causing programmers and managers to rethink the way programming is done. After listening to a group of developers here at Intel excitedly discuss ways in which they might implement XP, I became interested in learning more. One of the first things I did was read a book review and online discussion, one of many on the web. I still wanted to learn more, so last week I read the book. Even though everyone says the book is about programming, what the book is really about is dealing with change. Granted, the focus is specifically on how programmers can deal with change, but the basic “problem” of change is as common in testing as it is in development (if not more so). While reading the book, I looked for suggestions that might help testers deal more effectively and efficiently with change.
Kent Beck compares programming to driving a car. If you are driving a car, you don’t simply point in the general direction of your destination and hold down the gas until you get there. At least, I hope you don’t, even if you have an awesome off-road vehicle. Good, safe driving consists of making continual corrections until you reach your destination. If the road turns, you turn the steering wheel. If traffic is slowed to a crawl, you ease up on the accelerator. Extreme Programming takes the same approach from a development point of view. Change is not “bad,” it’s just part of the journey, and you cope with it continually along the way. Extreme?
Are the ideas of extreme programming truly extreme? One of the basic principles of extreme programming is unit testing. In fact, extreme programming suggests that even before developers start writing code they should first design an automated unit test that will fail unless the coding task is implemented successfully. Once the unit test (which may include a number or smaller tests) is created, the developer writes code until the unit test stops failing, at which point the task should be successfully finished.
Every good tester knows that unit testing is important. So why is unit testing considered “extreme programming?” If you think of extreme as meaning “risky” or “unproven” then no, unit testing is not extreme. However, if you think of extreme as meaning “nobody else does it” then yes, unit testing is extreme. If every developer implemented unit testing then it could no longer be called extreme (in my opinion). In fact, programmers who didn’t write unit tests would be considered extreme (in an extremely negative sense of the word!).
Not all of the extreme programming principles are as obviously worthwhile as unit testing. For example, one principle that I am still forming an opinion about is “pair programming,” in which all programming is accomplished by pairs of developers. Instead of an individual programmer writing code and then having it reviewed later by another developer, coding is always done with two developers working together. I can certainly see the benefits, especially with complex code. However, pair programming is new to me and still relatively unproven. It seems more “extreme” to me because not only does “nobody else do it” but it also seems more “risky” and “unproven.” If we are fortunate enough to work for a company that promotes informed risk-taking then we can try implementing the principles of extreme programming that we think might help. How do I keep things under control?
Extreme programming doesn’t claim to have the solution to every problem. You may be familiar with the phrase, “Our product variables are cost, time, and quality — choose any two.” If you can decide to keep costs low and still deliver a product in a short time, quality will naturally suffer. Or if you choose to have high quality in a short delivery time, the development costs will skyrocket. You get the idea. Extreme Programming doesn’t get around this.
Chapter 4 of Extreme Programming Explained does carry this idea a little further by adding a fourth variable, scope. Now we have cost, time, quality, and scope, and management may choose any three of the four. However, you can’t have everything, no matter how extreme your programming may be. I am a test engineer: does extreme programming apply to me?
At this point you may be wondering, “Does extreme programming apply to me, the test engineer?” An excellent question! Extreme Programming consists of principles that help developers to embrace change. Extreme Programming recognizes that change happens, and suggests effective processes that help deal with change.
Testing deals with change every day. Software changes, requirements change, jobs change, schedules change, processes change, environments change, even our cube and building locations change. We can either fight those changes (and seldom be successful), or we can facilitate those changes. We may need to implement Extreme Testing to be more successful. What can I do now?
I wish I had more ideas on how to embrace change within testing. Maybe someone will write a book on Extreme Testing. Maybe it will be you. If so, please hurry! As a testing organization we need to work together to figure out ways to effectively cope with change. We need to take informed risks and find better ways of working.
The first and usually the most difficult step towards embracing change is to identify a specific problem. Once you identify and characterize a problem, use your creativity to come up with possible solutions. If you focus on one problem at a time it’s much easier to find a good answer.
So, what’s the problem? You don’t have enough training? Work with your manager to obtain training. Maybe you take a class. Maybe you read some books. Maybe you attend a conference, or obtain computer-based training, or find a mentor. If you can identify the specific need, you can probably find an “extreme” solution. You don’t have automated testing? Take some risks and be extreme by automating a few small yet critical tests.
You don’t get along with the developers? Try taking them out to lunch, or bringing them toys, or playing laser tag. These ideas may not work for you, but don’t rule out an idea just because “nobody else does it.”
You don’t have enough time to sufficiently test? Hey, welcome to the world of testing. You’re going to have to figure that one out on your own. And let me and everyone else know if you find an “extreme” solution! Conclusion
As testers we want to embrace change. We want to improve our processes, even if our improvements seem “extreme.” If you have ideas for improvement then you have the opportunity and the responsibility to share your ideas with those you work with. The testing group that I work with recently underwent an “extreme” reorganization in which we broke out from underneath the development group, thus becoming more of an independent organization. Some people say the move was too extreme, but I think it was an important step towards embracing change, one that gives us more freedom to implement “extreme testing” the way we think it should be done.