Learn how one tester brought developers into the test lab and discovered that by exploring software with testers, developers can learn how their software might be used and testers can learn more about the application itself.
As a black box tester working on a variety of development projects, I was often approached by developers who were trying out test-driven development and wanted to learn more about testing. To show them how I worked. I involved them in pair testing, a technique in which two people test an application at the same computer. Interestingly enough, the developers taught me as much as I taught them.
Let me explain how it worked. Before a pair testing session, the developer and I would meet to determine the focus and scope of the test. We would pick an area of the program to test and establish our goal. Sometimes the goal would be to track down an elusive bug, sometimes to ensure that customer acceptance test criteria were met, or sometimes to find bugs in a new piece of functionality. We would write our goals and testing ideas on a whiteboard, keeping a copy of the finished notes for our own use.
Later, the developer would join me at the computer. He would watch how my exploratory testing techniques led to new ideas and plans of attack. Soon, he too would be actively testing. As the sessions progressed, we would revisit our goals and come up with new ideas for testing.
The benefits of pair testing extend beyond the developer and tester involved. Developers learn how to test their own code more effectively and gain a new perspective on how their software might be used. Testers gain a more thorough understanding of the application they are testing and learn debugging techniques to find causes of defects. Both developers and testers learn how to uncover more information to write more effective defect reports. Additionally, pair testing can break down communication barriers between developers and testers and facilitate team building.
During pair testing sessions, developers regularly told me that they had never thought of looking at software testing the way I did. The "what would happen if I tried this..." mindset was not as intuitive to them. They tended to think of tests that reflected a typical way of using the software; I thought of tests that might cause failures. As I applied my usual techniques they typically would say something such as, "Stop! Slow down! What are you doing?" Then I would stop and explain my reasoning. The types of bounds conditions or input validation tests that I immediately tried on input fields of new features surprised them. They were also surprised by my attempts to get around the control flow of the program.
The developers weren't the only ones learning something new. I was often struck by how developers' perspectives and testing techniques were different from my own. I tend to focus on the user's perspective, while developers tend to focus on what the program tells them about what is going on behind the scenes. As they shared their knowledge of the underlying code, I learned what areas of the product might contain weaknesses and gained application-specific knowledge that helped me track down problems more effectively and provided more information when reporting a defect.