01/21/2009 by Ruben Meier
Testing departments use HP Quality Center (QC) for quality management and testing activities. Besides managing test requirements, it also helps them to compile test plans, and to conduct and monitor testing. In addition, Quality Center gives them a way to manage all defect tracking.
However, developers often work with their own tools to manage bugs and defects, and to monitor problem-fixes. This is the case for example with Jira created by Atlassian Software Systems, which is primarily a tool for bug and issue tracking. Quality Center’s actual strengths, namely managing test requirements and test cases, are not effective in this utilization realm. Developers sometimes consider an additional tool as dead weight and far less user-friendly compared to already known tools such as Jira. For that reason, many developers are reluctant to work with QC and prefer “their” Jira.
Since using QC offers many advantages thanks to its high transparency and structure in terms of test management, QC and Jira are nevertheless used side by side in actual practice for the purpose of defect tracking. This results in a duplication of effort, less transparency, and additional complexity due to communication needs and media-related disruptions. Furthermore, synergies between the test and defect processes are not tapped.
An interface between these two tools could result in each role being carried out using the tool best suited for a given task. Such a bridge combines the tools pertaining to integrated process support and creates transparency throughout the entire test and defect processes, while also being able to manage and optimize them.
A defect management cycle for an error discovered by the testing department would appear as follows in a project:
|Tester||The error is discovered by a tester and recorded in QC as a defect. Descriptions and attachments (e.g. screenshots) can be attached.|
|Test Manager||The test manager assigns the defect to a developer and thereby clears it for troubleshooting.|
|Bridge||The defect along with all details is forwarded to Jira and thereby handed off to the development department.|
|Developer||Developers can correct the defect that is now present in Jira, or if the defect cannot be reproduced, they can obtain additional information or close the request.|
|Bridge||This status change is reported back to QC and test management is notified of the current development status.|
|Tester||Once the defect is corrected, QC performs the test again, after which the defect status can hopefully be changed to “closed.”|
|Bridge||The bridge forwards the “closed” status to Jira, thereby ending the defect correction process.|
Should the defect recur, the status is changed from “closed” to “reopen” and the trouble-shooting sub-process is re-initiated.
However, one should not create a suitable interface between QC and Jira based solely on an individual project’s requirements. The key is to have a flexible interface that one can tailor to specifications of new projects by means of simple configuration. Ideally, a QC-Jira bridge should be able to synchronize any given project-specific areas that fall under QC and Jira’s capabilities. In the event of further expansion, it is also critical to ensure that the organization of test management and development departments is geared toward the new, shared, integrated, and tool-supported process.
Summary: Integrating Jira and the Quality Center
beteo implemented an interface between Jira and QC at a large-scale Swiss transportation company. Thanks to the interaction between the two systems, all individuals involved in the projects can work with the tool best suited for their respective needs. Developers, test managers, and testers utilize the product tailored to their tasks. In this way, defect and test management are combined, simplified, and, thanks to a reduction in redundant activities and communication complexity, more cost-effective.