␡
- Experience 1: Early Success
- Experience 2: Challenges
- Lessons Learned
- Integrating Conventional Software Testing on an XP Team
< Back
Page 4 of 4
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Integrating Conventional Software Testing on an XP Team
Following are some suggestions for making the most of your experience as a software tester on an XP team:
- Try to understand the XP development process and the motivations behind it. Read Kent Beck's Extreme Programming Explained. Use the online resources at XProgramming.com and XP123.
- For information on how to test in this environment, read Cem Kaner's papers "The Role of Testers in XP" and "The Ongoing Revolution in Software Testing."
- Let go of preconceived notions of how you think a development process should work. Drive out fear, and give the methodology a try.
- Use the XP values as an overall guide for your working attitude and behavior. Not every answer to every problem will be written down, but the values are there for guidance.
- Read XP-related testing publications, but don't be discouraged if some of what they say opposes conventional testing activities such as manual testing. Be open to new ideas, but have confidence in your skill as a tester. Experiment—and stick with what works, not what seems to be popular in publications.
- Don't expect to base your testing on a requirements document written at the beginning of the project. Much of the communication will be face to face, with requirements for an iteration written on index (story) cards.
- Be proactive in getting information on what needs to be tested. Question developers, customers, and other team members; then use your judgment and skill as a tester to figure out what to test.
- Beware of vague language. For example, words such as test or tester on an XP project often refer to developers and automated unit testing. Always ask for clarification on shared language to be sure that everyone is on the same page.
- Understand that you may seem to share the same language with developers, but your terminology might have different meanings in their context. Always ask for clarification.
- Think of prewritten tests that guide development as examples. Think of tests that are designed to find potential problems as counterexamples.
- Work on your timing. Find out what developers want when they ask for
feedback:
- A sounding board to talk about ideas
- Test ideas to guide development
- Test ideas to firm up a design
- Light testing for quick feedback on a story under development
- Heavy testing on a finished story
- Work with customers to help them understand risk, and support them on uncomfortable areas. Discomfort is usually a sign of usability problems or incoherent stories.
- Don't worry about fault-tracking systems. You may simply write bug reports on story cards.
- Accept feedback. Listen to the developers' and customers' needs. Be empathetic and supportive; don't try to enforce a process.
- Use your expertise to look for answers and think of creative solutions. Much of what you already know as a tester is effective on any software project.
- Strive for continuous improvement, and be ready to try new testing activities to see what works well. Work on improving your skill as a tester.
- Get ready to be challenged—and to learn a tremendous amount.
< Back
Page 4 of 4