Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Lessons Learned
Working on an XP team as a conventional tester has shown me that good, thoughtful, skilled conventional testing and Agile testing can be complementary. On an XP team, where most of the focus is on automated unit tests and other test automation activities, testers can plug conventional software testing activities into this environment. Testers need to adapt to a developer-centric methodology that values technical skill, rapid feedback, and close collaboration within an iterative lifecycle.
On an XP team, you literally all work together in a shared space, which poses special challenges for nonprogrammers. Developers know their role and have a lot of guidance on execution of activities. Nonprogrammers usually have less support in XP, and it can sometimes be difficult for developers to think of non-programming activities for the testers.
When working as a tester with developers in the same workspace, I learned that it's important to understand what developers need. Timing is essential. When developers are brainstorming about a design idea, they may be looking to you as a sounding board, not for test ideas. If you overwhelm the developers with counterexample test ideas at this point, they'll be frustrated. If developers are working on a story and want quick initial feedback, it's counterproductive for you to point out every flaw you see, digging in deep and trying to make a feature fail. There is a time for that technique: when the developers have finished the story. As a tester, you need to communicate with developers and find out what they want. They'll rely on you for test ideas and expect you to try to break the software they've developed, but they'll also rely on you for positive support and for examples to help drive development.
Both sides are responsible for good communication; developers need to tell you when you're providing feedback that isn't useful. Unfortunately, we don't always notice this situation at the time, so it's a good idea to ask for clarification. For example, if I'm generating test ideas and get strange looks, I ask the developers if this is the kind of feedback they want. After a while, they learned that they could tell me to hold off on test ideas, and request that I be a sounding board for a new idea. It's also a good idea to clarify terms such as test, tester, and so on that may appear to be part of a shared language. In XP circles, many testing terms can mean something different than the definitions that conventional testers are used to.
For testers, adapting to XP teams can be a challenge, but the benefits can be enormous. The code is always available to be tested, developers and customers are also testing, and test work can be done at any time during a development project. Adapting to requirements coming in the form of story cards, getting used to writing bugs on story cards instead of in a fault-tracking database, and being willing to step up and work on tasks that need to get done can all be rewarding.
Don't be surprised if there's a lot of talk at first about the team not needing your skills. In my experience, there's a lot to be learned from focusing on adding value. If I'm providing value, I stay on. If not, I look at other options. In my experience, and that of other testers, most of the resistance to conventional testers disappears once developers and testers start working together on a project.