"Pair Testing and Developer Tester Collaboration"

IndicThreads >> You have also been involved in pair testing with developers. Can you tell us more about pair testing and the dos and donts of effective pair testing?

Jonathan Kohl >> Pair testing for me is about learning, and about joining forces with another skilled practitioner. Ive written an article that people have found helpful Pair Testing: How I Brought Developers into the Test Lab There are some dos and donts in there that you might find useful.

"Timing as a tester is really important..."

Something Ive learned since I wrote that article, particularly from working on Scrum and XP teams, is that timing as a tester is really important. I am a musician, so I think of a project in terms of a song, or a compositional piece that a band is performing. Each role has a part to play, and those parts change over the course of a piece. The same thing happens every day on a project.

"I learned that there is a time and place for bug finding and test idea generation."

When I first started working all day, every day with Test-Driven Developers, I put too much pressure on myself to constantly come up with testing ideas. I overwhelmed developers at certain times, and at other times they thrived on my ideas. I learned that there is a time and place for bug finding and test idea generation. Sometimes they want to bounce ideas off another systems thinker, and arent ready to think about bugs. Other times, they want a second opinion on a design, so if I go into full-on bug-finding mode, I will frustrate them. Once a task is complete, the developers would say: Do your worst! Tell me where the problems are, and they learned that bugs are a good thing for us to find. They appreciated the work I could do to expose problems. That isnt all of what testing is about though  focusing all the time on test idea generation and finding bugs can be like playing the same part over and over in a song. Your band leader and your audience are going to get frustrated.

"Focusing all the time on test idea generation and finding bugs
can be like playing the same part over and over in a song...."

Jonathan and Heidi

I work on my timing when it comes to testing activities, and see how testing can help developers throughout the project. This can vary depending on the team and the people I work with. In some cases, I spend time teaching developers how to do functional testing, and they teach me more about unit testing. Recently, Ive worked with more and more developers who were misled by the Agile-Testing folklore that automated unit testing encompasses software testing.

Ive worked with more and more developers who were misled by the Agile-Testing folklore that automated unit testing encompasses software testing.

They are shocked that even though all their automated unit tests pass, the program fails basic, manual scenario tests. So I work with them some of the time teaching them how to think more like a tester, and to do manual functional testing in conjunction with their TDD work, as well as my own testing. I usually see a marked improvement in the code they deliver once they start doing more testing on their own work, testing in contexts other than the source code.

IndicThreads >> Testers Vs Programmers is a conflict situation we see quite often in teams. What's your take on the subject?

Jonathan Kohl >> There doesnt need to be a conflict. My testing career is a testament to the fruitlessness of that conflict. Heres just one example:
I was testing a web application that had an intermittent bug. I was working on getting a repeatable case so we could fix it and I joined forces with a programmer. For about an hour a day, we would sit at one computer, and test together. His knowledge of the code and automated unit tests, coupled my Exploratory Testing were a great combination. We quickly got to the bottom of some of the issues we were investigating by working together. We learned from each other, and ideas that we realized when we understood the others perspective were a catalyst. It was a lot of fun, even though we were under a lot of pressure. When we worked together like this doing exploratory learning, the ideas would rapidly chain together like a kind of quicksilver. This collaboration sparked a creative energy that lead to vital discoveries in software design as well as testing.

We then spent time away working on other tasks, and investigated issues based on our skills and view of the program. Thanks to his insight and our testing sessions together, I was able to amass a great deal of information very quickly. Within a couple days of a productive pair-testing session, I found a repeatable case. Without our pair-testing, Im sure we would have found the problem, but it would have taken much longer if I would have been on my own. That exchange of ideas carried forward  now I knew a lot more about the application I was testing, and I was able to test more effectively later on. I also knew how to relate to the programmers better, and to be able to speak their shared language better. That helped me develop a better relationship with them.

"The more knowledge Im armed with from collaborating with developers, the more creative I can get with testing..."

There is an enormous potential to learn from each other and to complement each others work. If developers are testing more, then I can do different kinds of testing and work on more interesting problems. The more knowledge Im armed with from collaborating with developers, the more creative I can get with testing. I thrive on working in that collaborative space.