The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #8: Pair With Developers
The idea of pairing is closely coupled with Extreme Programming and the Agile movement. Some organizations do most, if not all, of their primary development in pairs. The reason? Two people have a conversation. They talk out their ideas and reasons for doing certain things. The pair is accountable to one another, and in the process of that accountability, the work that is done is often of higher quality and the pair is more productive working together than they would be working separately. This is not always the case, of course. Some programmers work better solo, and have a hard time participating in a pair arrangement, but generally speaking, there's a synergistic effect in pair programming situations where the whole is greater than the sum of its parts. Testers often use the same approach when they are looking at software, too. The ability to have two eyes looking at the same story can help by having two perspectives and two different approaches used, and when one person thinks of a test idea, the other tester may follow on with a totally different idea.
Pair programming? Check. Pair testing? Also check. Pairing a programmer with a tester? See below.
Workshop #8: Practice the Driver/Navigator Method of Pairing
Between Pair Programming and Pair Testing is a middle ground that I like to call the "Driver and Navigator" space. With this model, both the programmer and the tester take turns as both the driver and the navigator. While the programmer is writing the code, the tester asks questions and gets clarification as to what is being implemented. While the tester tests, and articulates what they are testing, the programmer often gets new insights, and can go back and modify the code based on the areas being tested. Why is this effective?
First, it's effective because the programmer, while writing the code, explains what they are doing conceptually to the tester. Think of it as the driver explaining to the passenger in a car what they are going to see while they travel along their destination. The passenger could just sit there and take in the scenery, but often, the passenger might choose to be proactive, and say "you know, there's this cool area on this side road that might be fun to travel down, and it might save us some time, since we know the section of freeway ahead is prone to traffic". With that, the driver can opt to switch course, or consider another route altogether.
Second, the tester, by virtue of getting a play by play of the developer writing the code, can ask questions and get clarification ("I noticed that you have set up the page with his set of IDs. are you planning on providing alt tags for each of them? That will help with accessibility.") By doing this, the tester actually starts testing the code as it is being written, and the developer, receiving the feedback, has the ability to "fix bugs" in real time.
Third, even a non programming tester, if they are following along as a programmer writes the code, might notice inconsistencies within the code and comment on them. "Oh, so you're calling this procedure at this point, and you're calling this other procedure over here. Do the two procedures need to interact with one another?" That comment might help a developer notice that "Oh yes, you're right, if I don't scope the variables, they will not be handled correctly when passed to each other.
Bottom Line:
Programs in their finished state can seem very impenetrable and hard to understand. While they are being written, and with a guide to explain what they are doing, programmers can illustrate small sections of code even to those who have little knowledge of programming. Likewise, in the process of this design and build-up, testers have a great opportunity to ask questions and help guide the programmers to ensure that they are really doing what they think they are doing.
The real value of this interaction is the conversation, the give and take of both parties as the code is being written. This will not work for every story, but it will work a great deal of the time. If you have a programmer that's willing to work with you in this capacity, try it out. Sitting side by side is the best approach, but if that's not possible, sharing a screen session and using a chat client can be very effective as well (in some ways, even more effective, since you have a transcript of what was discussed). Using the driver/navigator method, over time, you may also find that you become more comfortable with the coding aspects as well, and then you may find yourself gravitating towards more more of a peer programming model. Frankly, that wouldn't be a bad outcome at all :).
No comments:
Post a Comment