Bonding Over Bugs

Computerworld -

Premier 100 Now! Premier 100 Weblogs

It's safe to say that developers and testers are guided by different motives, pressures and perspectives. Developers are motivated to complete code quickly and accurately and move on to the next problem. Testers are required to find and report problems within the system quickly. Someone should be urging developers to improve the quality of the code they create or modify, but that often takes a back seat to "more code, faster." And someone should be inspiring testers to find more-meaningful bugs, but I rarely see that happening.
In the course of a project, the more defects testers find and submit to developers, the less time developers have to work on them, and communication may break down. Members of the project team commonly start to rely on entering short descriptions and comments into a defect-tracking system as a means of communication. This often leads to misunderstandings and unnecessary tension between the two groups. I have found some techniques that can improve communication between testers and developers and help them fix problems faster.
Share Automated Tests Between Teams
Test teams often develop system-level test scripts using commercial tools, and developers frequently design unit-level test scripts using open-source frameworks. If your project team isn't doing either, ask them why. There are plenty of good reasons not to use automation, but make sure the teams have at least considered it. If either team has automated tests, get them to start sharing.
Sharing test scripts gets everyone on the teams using the same tools and languages. That makes developers more likely to offer improvements to the scripts and testers more inclined to offer advice on data selection and common test patterns. Sharing test scripts also minimizes redundancy and typically leads to increased test coverage. The more testers and developers collaborate, the more powerful both their scripts become. Microsoft Corp., IBM and others have excellent integrated development environments built for this type of collaboration.
Distribute the Ability to Execute Smoke Tests
Every time developers compile code (often referred to as a "build"), there's the potential for something to go wrong. To detect a bad build early, it's helpful to create a series of preliminary tests -- commonly called smoke tests -- that exercise the system from end to end. A smoke test doesn't have to be exhaustive, but it should be capable of exposing major problems. If the build fails the smoke test, the developers will probably need to go back to the code to debug and find the problem.

Michael Kelly is a testing consultant at Fusion Alliance Image Credit: Larry Ladig