Breaking Down QA Communication Barriers

Developers, testers and scripters all contribute in very different ways to the quality of a product. They deploy different tools and technologies, and are often geographically separated by time zone — even language. Thus, collaboration and communication between individuals working on a block of functionality can be significantly hampered.

Conversely, when development and testing are co-located, both groups inevitably seem to regress to the "come look at this," shoulder-to-shoulder communication style. This fixes some of the communication issues but does not resolve poor documentation, and is a local solution at best.

This quarter, the QA Insider takes a close look at "dirty laundry" no one wants to claim: the communication challenges between developers and testers in the QA process. We'll examine how traditional — and often accepted — ways of communicating can result in multiple bugs and bog down efficient product development. Finally, we'll discuss how you can overcome the communication obstacles common to the testing process.

Developer-to-Tester Communications Issues

It's almost cliché to say, but unless the right hand knows what the left hand is doing, the potential for undiscovered bugs increases dramatically. One of the key areas where this happens is when testing a large quantity of new features. Consider the following scenario:

Testers are tasked with the initial testing of new features arriving from development. They are also charged with creating documented test cases to be incorporated into a test plan for the new release. However, it's unlikely that the developer had the time and tools to document the test setup and procedures used in the development process. This leaves testers with little more than a marketing or engineering spec on the new feature, and no data about the tests performed in development.

Rarely will any of the knowledge get successfully transferred from the developer to the tester. The tester then has to spend a significant amount of time and effort getting up to speed on the new feature, and then develop a "positive test case" that presumably duplicates what the developer did with the feature.

The bottom line: Failure to leverage or exploit the efficiencies associated with proper knowledge transfer from development to test can result in a significant time crunch for the tester to design and perform more thorough testing (negative testing, feature interaction, boundary testing). Thus, the likelihood of discovering bugs is unfortunately reduced because less time is spent testing.

Tester-to-Developer Communication Issues

Sometimes it's not only breakdown of communication that drives you insane, but also inefficient communication paths. Consider this common example:

When testers discover what they believe to be product defects, they may enter information into a formal bug tracking system. Or, they may simply check with the developer in person, by phone or email to certify 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 was not performing. However, a simple or high-level overview often won't include a detailed log of their activity, leaving it challenging to recreate the testing process.

And, if the defect does appear to be true, some developers may want to investigate the defect on the tester's testbed in person, tying up the tester's workstation and leading to further inefficiencies.

Bridging the Communication Gap

The scenarios above clearly demonstrate that too many variables significantly raise the margin for error. What is missing in most organizations is a way to standardize communications that identify steps in the QA process. Here are some examples of what's typically missing from most QA processes:

Tools to Capture Every Interaction — Developers and testers need tools in place in which every interaction performed is captured and automatically logged and stored. In addition, they need readable, structured and executable reports that include step timing, actions performed, and response data for all interactions.

Ensuring Smooth Handoff — To combat knowledge transfer issues, standard QA process should include capturing the details of a developer's "positive unit test" and automatically reporting the results to the responsible engineer, or filing it in 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.

Confirming True Defects — When testers need to confirm that an observed behavior is indeed a defect, QA processing should include electronic transmission of reports. This built-in efficiency is a viable alternative to interruptive and serialized "shoulder-to-shoulder" examination on the tester's testbed.

Summary

Clearly there are formidable obstacles to communication and knowledge transfer between development and test. The good news is Fanfare has these tools in place to deliver true QA testing efficiencies. Not only do we offer FanfareSVT, we've just released iTest Personal, a revolutionary new downloadable testing tool that systematically allows anyone with minimal training to instantly "capture", document, and communicate his or her interactions with a set of devices.

Our tools were designed to specifically improve communication between developers and testers, increase the effectiveness of the debugging process, and improve overall QA efficiency. Now you can automatically create a detailed activity report that can be electronically transferred so both testers and developers have the same high degree of visibility into the product development lifecycle. And ultimately, this leads to more efficient product development cycles and faster time to market.