Developers and testers in the network device space share a unique peer relationship, yet they often experience communication problems during the quality assurance (QA) process. One might think this is the result of using different tools and technologies, or working in disparate locations, separated by time zones and language. But even when development and testing take place in the same building, communication problems still exist.
Why? Traditional communication methods don't work for today's testing organizations. Devices are becoming increasingly more complex and require more testing prior to release. More than ever, interaction between developers and testers needs to be clear and efficient.
It's also important to note that communication problems between developers and testers are common, and not limited to small or new manufacturers. Some of the world's leading device makers have struggled with communication issues and paid the price—from more bugs to slowdowns in product releases.
With the right technology and a willingness to change behavior, testing organizations can overcome the communication obstacles common to the QA process. The key is to standardize communication practices.
Developers and testers face a range of communication issues—from misinformation to complete breakdowns—throughout the QA process. Both teams are committed to delivering a quality product, but neither has the communication practices in place to help them work together toward this goal.
For example, testing organizations often have no means of ensuring a successful knowledge transfer from developers to testers. This is particularly evident—and dangerous—when organizations must test a large quantity of new features.
Testers typically must perform the initial testing of new features arriving from development, as well as document test cases to be incorporated into a test plan for the new release. Yet testers seldom have more than a marketing or engineering spec on the new feature. They usually have no data about the tests performed in development. The reason: Developers did not have the time or tools to document the test setup and procedures used in the development feature validation process.
Testers then have to spend time learning about the new feature and developing a "positive test case" that duplicates what the developers did with the feature. This leaves testers with little time to design and perform more thorough testing (i.e., negative testing, feature interaction, boundary testing), and greatly increases the risk of undiscovered bugs.
Communication also can break down along the path from testers to developers, even when a formal system is in place. For example, when testers discover what they think is a product defect, they may enter information into a formal bug tracking system. Or, they may simply check with the developer (face-to-face or by phone or e-mail) to certify that it's a defect, and not an intended behavior or unsupported use case.
Most bug tracking systems require the tester to summarize (in words) and perhaps cut and paste data to prove the product or feature is not performing. However, a simple or high-level overview often won't include a detailed log of their activity, making it difficult for developers to recreate the testing process.
And, if the defect does appear to be valid, developers might need to investigate the defect on the tester's testbed, tying up the tester's workstation.
Testing organizations can resolve these problems and increase efficiency by standardizing communications throughout the QA process. This requires a combination of testing tool technology and personal commitment. Following are a few proven methods:
* Capture every interaction: To facilitate effective communication, developers and testers should have tools that capture, automatically log and store every interaction. In addition, they need readable, structured and executable reports that include step timing, actions performed and response data for all interactions.
* Document test cases in the language of the device: To ensure that the test cases can be read and universally understood by all testers and developers, no matter their location, language, or scripting expertise, test cases should be documented in the language of the device.
* Ensure a smooth hand-off: To combat knowledge transfer issues, a standard QA process should capture the details of a developer's "positive unit test" and automatically report the results to the responsible engineer, or enter it into a document management system.
* Facilitate meaningful communication: To resolve communication issues found in typical bug reports, QA testing should include a comprehensive report of the tester's activities, giving anyone reviewing bugs complete data. The report file should also be executable, if reproduction is necessary.
* Confirm true defects: To help testers confirm that an observed behavior is indeed a defect, the QA process should include electronically transmitted reports. This built-in efficiency eliminates interruptions by developers who want to access the tester's testbed.
With the right tools and techniques, testing organizations can improve communication between developers and testers, increase the effectiveness of the debugging process and improve overall QA efficiency. This represents a win not only for developers and testers, but also for management by providing efficient product development cycles and faster time to market.
About the author
Tom Ryan (email@example.com) is president and CEO of Fanfare (Mountain View, Calif.). He earned a BSEE from Manhattan College and has advanced training in electrical engineering from New York Polytechnic University.