A Visualization Approach for Bug Reports in Software Systems

Transcription

1 , pp A Visualization Approach for Bug Reports in Software Systems Maen Hammad 1, Somia Abufakher 2 and Mustafa Hammad 3 1, 2 Department of Software Engineering, The Hashemite University, Zarqa, Jordan {mhammad@hu.edu.jo, somiaf@itc.hu.edu.jo} 3 Department of Information Technology, Mu'tah University, AL Karak, Jordan hammad@mutah.edu.jo Abstract For widely-used and large software systems, there is huge number of daily submitted bug reports. These bug reports are mainly submitted by different developers with different roles during software development process. Therefore, understanding and monitoring the status of all submitted bug reports is not an easy task. Each bug report has various and different statuses over time. Furthermore, the relationship between bug reports and developers is complicated and hard to detect. In this paper, we propose a solution to help software project managers or bug trackers to understand the current and the previous statuses of large number of submitted bug reports. We propose a visualization approach to model the different statuses of bug reports and their relationships with developers who work on them. The visualization is based on extracting information from bug tracking systems and modeling them in comprehensive and meaningful views. Keywords: Software visualization; bug reports; bug tracking 1. Introduction Software repositories of large projects are typically accompanied by a bug report tracking system. Bug tracking systems play an important role in open source software development [1]. They are mainly used by software developers and quality assurance teams to provide feedback about bugs in the system and/or fix them. Bug tracking systems provide useful information for each reported bug by including useful properties such as the description, the severity, the developer assigned to fix the bug, etc. Large open source software systems usually have large bug repositories. The bug tracking systems in these projects receive large number of bug reports. Furthermore, the developers belonging to these systems are distributed and not centralized. So, determining the status of all submitted bugs reports is not an easy task. There are multiple statuses of each bug report in its life cycle. There are also many roles for developers in each submitted bug report. In the literature, there are many researches on triaging and assignment as in [2] and bug reporting [3]. Many tools and approaches have been proposed to facilitate the process of bug handling. One aspect of bug processing that need to be examined is the application of visualization techniques on bug tracking systems. Visualization directly supports program comprehension and it is useful to understand large volume of data. Project managers need to understand the statuses of large number of submitted bug reports. Visualizing the statuses of these reports saves time and efforts comparing to textual reports provided by bug tracking systems. Furthermore, it can provide rich information about different reports in one view. The main goal for the proposed visualization is to improve understanding the statuses of bug reports in a comprehensive way for project managers. ISSN: IJSEIA Copyright c 2014 SERSC

2 This paper is organized as follows. Section 2 provides a brief description about bug reports. The proposed visualization is detailed in Section 3 followed by the proposed framework in Section 4. Related work is discussed in Section 5 followed by conclusions and future work in Section Bug Reports A bug report is used by developers or users to report and describe a bug in software projects. A set of bug reports are widely used in open source projects to keep track and archive different faults that may lead to partial or complete project failures. In this paper, the proposed visualization is based on the Bugzilla ( bug tracking system. It is widely used in open source software projects. To understand the various statuses of any submitted bug report, Bugzilla provides a complete description for the life cycle of bug reports. At any time, each submitted bug report can be in a specific status based on the actions performed on that bug. Bugzilla describes the following main fields for each submitted bug report: A unique identifier number A description of the problem The problem location in the project A priority level from 1 to 5 measured by its severity and criticality. The involved people, which includes the reporter of the bug and the assigned developer to fix it The conditions in which the bug was detected, such as operating system and platform. The bug status, which indicated wither the bug is opened or closed. According to Bugzilla [4], an opened bug may have one of the following five statuses: Unconfirmed: when a bug has been assigned and waits for someone to handle with or classify it. New: when the reported problem is classified as a new real bug Ready: when there are enough information available in the reported bug to let a developer able to start repairing it Assigned: when a developer chooses a bug to begin the repairing process on it. Reopened: when the bug was resolved once before but the solution seems to be not right. A closed bug can be either Verified or Resolved; verified bugs mean that the reported bug has been fixed, and the fix has been confirmed by a developer who is not the bug reporter. When the developer finishes working on a bug it is considered as resolved. Resolved bug may have several possibilities: Fixed when the bug has really been repaired. Invalid when the problem assigned has been classified as not a real authentic bug. WontFix when the developer closed a bug but could not repair it. Duplicate when the new assigned problem was reported before in an older bug, or it has the same reasons of another one. WorksForMe when the developers did all their efforts to repair this bug but not succeed. Incomplete when the assigned problem was not evident and developers do not have clear solutions to repair it. 38 Copyright c 2014 SERSC

3 For example, Figure 1 shows a reported bug for the Eclipse project ( The bug ID is As shown in the figure, there are many fields in the report that are given by Bugzilla and are filled by the reporter of the bug. The status of the bug is NEW, its severity is normal, and its priority is P3. Summary: Generated Editor saves no fixed XML-attributes Product: [Modeling] EMF Reporter: Hartmut Schweizer <hartmut.schweizer> Component: Transaction Assignee: EMF transaction inbox <emf.transaction-inbox> Status: NEW --- QA Contact: Severity: Priority: Version: normal P3 Target Milestone: --- Hardware: Unspecified PC OS: Windows 7 Whiteboard: Description Hartmut Schweizer :56:27 EDT I have generated an Editor based on XSD. Problem: following Codeline: <xs:attribute name="occi.category.term" type="xs:string" use="required" fixed="undefined_link"/> The generated Editor shows "undefined_link" for the attribute in the GUI but when i save the file, there ist no attribute setted in the file, even when i click in the editbox an change an rechange the data "undefined_link" to "undefined_lin" to "undefined_link". I have to realy change the data, that it gets saved. Figure 1. The Fields of Bug from Eclipse Project Table 1. Shapes and Colors used in the Visualization Closed Bug Reports Opened Bugs Reports Status Closed Modeling Status Opened Modeling Resolved but not verified Resolved and Verified Red Bright green Unconfirmed New Assigned Reopened Ready Gray Yellow Blue Pink Orange 3. The Proposed Visualization Based on the definitions illustrated in Section 2, each bug life-cycle phase is modeled by a different shape and a unique color as shown in Table 1. There are different shapes for closed and opened bug reports. Each status, within opened and closed bugs, is modeled by a different color. Figure 2 shows a simple example for the using of colors and shapes to model the status of bug reports. Each shape is then marked with bug Id, severity and priority. Copyright c 2014 SERSC 39

4 Figure 2. Bug Reports Statuses Shapes and Colors R e s o lv e d th e b u g P a r tic ip a te d in th e b u g A s s ig n e d to th e b u g D e v e lo p e r Figure 3. Developer and His Different Roles The proposed visualization also models developers and their relationships with bug reports. Each developer is visualized as an actor icon and his role as an arrow connected with the bug report. The role of the developer is modeled by the shape of the arrow. If the shape of the arrow is solid and bold, it means that the bug report is already assigned to the developer. A solid shape of the arrow means that the developer resolved the bug successfully. Dashed arrow means that the developer participated in handling the bug. The visualization of developers and their roles are shown in Figure 3. The proposed visualization generates two different views for bug reports. The first view models the current statuses for a group of bug reports. From this view, we can identify the up to date status for each bug. The second generated view shows the life cycle of a specific bug report. In this case, all previous statuses for a bug report are modeled and visualized The Current Status View The current status view models the up to date statuses for multiple bug reports. It visualized the selected bug reports in one view as well as the developers related to these selected bugs. This view is useful for project managers who want to get a brief summary about the current status for bug reports in the bug tracking system. For example, it can be used to answer the following questions: Who are the developers currently working on a specific bug or group of bugs? Who are the developers previously working on a specific bug or group of bugs? Who are the developers resolved the largest number of reports? Who are the developers could not fix large number of bugs? How many reports a developer has resolved? 40 Copyright c 2014 SERSC

5 Figure 4. A Current Status View for Selected Bug Reports from ArgoUML Project Figure 4 shows a real example for eleven bug reports that are extracted from the ArgoUML bug tracking system ( ArgoUML is an open source project for drawing UML diagrams. Each bug is modeled by a colored shape. Bug 4931 and 5198 are the only opened bugs. But 4931 is new with priority (P4) and it is assigned to bobtarling. Meanwhile bug 5198 is reopened and processed by dthompson. Each bug is connected with at least one developer. For example, bug 4919 is connected with tfmorris and linus. From the shape of the arrow we can identify that tfmorris resolved the bug. We can also know from the dashed arrow that linus participated in resolving or handing the bug. Another example, bug 5815 is a closed bug that was fixed by linus and with contribution from dthompson. The current status view provides useful information about developers and their roles. For instance, developer linus in Figure 4 is the most active one. He contributed in handling five bugs and in closing three. Figure 5. A Life Cycle View for Bug 4468 from ArgoUML Project 3.2. The Life Cycle View The second view in the proposed visualization is the bug life-cycle view. This view visualizes the previous statuses of a specific bug that is selected by the user. In this view, all historical information is extracted from the bug tracking system in order to visualize all Copyright c 2014 SERSC 41

6 previous statuses of the bug. Each different status is modeled with a separate shape and it is marked with the date of status change. Each shape is also connected with developer(s) who worked on that bug. The bug life-cycle view is helpful in tracking a specific bug to check all its statuses. It is also useful to identify all developers who involved in that bug and their roles. Figure 5 shows an example for the life cycle view. The figure shows the different statuses of bug 4468 from ArgoUML. When the bug was created it is assigned to tfmorris. On the bug was resolved and marked as invalid by the same developer. After that, developer linus verified and closed it. 4. The Framework The proposed visualization is generated by applying the proposed methodology presented in a framework. The proposed framework s components are shown in Figure 6. In this methodology, the user, who is here a developer interested in the project s bug tracking, selects a specific bug to visualize its life-cycle history, or chooses a set of bugs to visualize their current statuses. Bug life-cycle Explorer extracts all previous statuses for the selected bug. This is done by tracing all historical information that is saved in the bug tracking system related to the bug report. As a result, this process generates a list of historical changes applied on the bug report under consideration. The Bug-developer Explorer component is responsible for finding the relationship between developers and bug reports. It discovers the type of the relationship between the developers and the different statuses of bug reports. Therefore, Bug-developer Explorer generates the bug s status with the related developers who work on that bug, and show the type of the connection between the developers and the reported bug. This process can be done for a specific bug or a group of bugs. The user may select a list of bugs to visualize their current statuses. In this case, the Current Status Finder will explore and extract all related information about selected bug reports to find their current statuses. As a result, the up to date statuses for the selected bug reports are extracted. In the next phase, the Bug-developer Explorer component finds the developers who worked on the bugs and identifies their roles. Finally, the Modeler processes the extracted information about the bug reports to generate the views. Figure 6. The Main Components of the Proposed Visualization Framework 42 Copyright c 2014 SERSC

7 5. Related Work The most related work to our visualization is the work done by Dal Sasso and Lanza [5, 6]. They presented an approach to visualize bug reports through a web-based software visual analytics platform. It allows users to navigate and inspect the vast information space created by bug tracking systems. Our approach differs in the visualization technique and in visualizing the roles of developers who worked on the bugs. Halverson et al., presented a number of visualizations [7] to support the coordination of work in software development, namely the Work Item History and the Social Health Overview. The Work Item History shows status changes of bug reports. The Social Health Overview provides an interactive overview of bug reports with drill down capabilities. D Ambros et al. [8] used data from a release history database to propose an approach to visualize the life-cycle of bugs, with the System Radiography and the BugWatch View; they provide a tool to focus on time, activity and severity/priority aspects of bugs. The System Radiography aims at studying the bug database in the large. The visualization is helpful to understand how the bugs are distributed in the system products and components and over time. The visualization is focused on bugs not on developers. Knab [9] et al. proposed a visualization approach for bug triaging and provide visual means to explore the effort estimation quality and the bug life-cycle of reported problems. Their approach is based on the Micro/Macro reading technique concepts and uses a combination of graphical views to investigate details of individual problem reports while maintaining the context provided by the surrounding data population. D Ambros and Lanza [10] proposed a language independent tool called BugCrawler to supports software evolution and reverse engineering. It is based on a combination of software metrics and interactive visualizations. BugCrawler integrates structural information computed from the source code with evolutionary information retrieved from CVS log files and Bugzilla problem reports to visualize evolving software systems. Hora et al. [11] presented the BugMaps tool that provides mechanisms to automate the process of retrieving and parsing software repositories data, algorithms to map bugs reported in bug-tracking platforms to defects in the classes of object oriented systems. The tool also provides visualization for decision support. Another map for bugs is presented in [12]. They developed a tool for visualizing large-scale bug location information. It displays bug localizations on a topographic map. To monitor class coupling, Hammad and Rawashdeh [13] presented a framework to automatically measure and visualize class coupling for object oriented projects. Pinzger et al., [14] proposed an approach focusing on providing visualizations for CVS, Bugzilla, and source code data taking into account the bug report details and in particular their life cycles. Fischer and Gall [15] used CVS and Bugzilla data to depict the evolution of software features. They use graph-based visualizations to project bug report dependence onto feature connected files and project directory structure. 6. Conclusions and Future Work In this paper we proposed a framework to visualize the statuses of large number of bug reports stored in bug tracking systems. The visualization also includes the developers who participated in handling the bugs and their roles. The visualization provides useful information about bug's statuses, information about developers, and the various statuses of specific bugs. The proposed visualization supports program comprehension by facilitating the information extracting process and understanding the different statuses of bug reports and developers roles. Copyright c 2014 SERSC 43

8 We are currently working on the implementation of the framework to make it fully automated. We aim to realize the framework as a tool that automatically examine bug tracking systems and generates the views. We also aim to extend the framework to visualize bug locations in the source code and the effect of fixing a bug in the source code. References [1] A. Mockus, R. T. Fielding and J. D. Herbsleb, Two case studies of open source software development: Apache and Mozilla, ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 11, no. 3, (2002), pp [2] J. Anvik, L. Hiew and G. C. Murphy, Who should fix this bug?, Proceedings of the 28th international conference on Software engineering, (2006), pp [3] J. D. Strate and P. A. Laplante, A Literature Review of Research in Software Defect Reporting, A Literature Review of Research in Software Defect Reporting, vol. 62, no. 2, (2013), pp [4] Mozilla, The fields of a bug in Bugzilla, [5] T. Dal Sassc and M. Lanza, A closer look at bugs, Proceedings of the First IEEE Working Conference on Software Visualization (VISSOFT 2013), (2013), pp [6] T. Dal Sasso and M. Lanza, In*bug: Visual analytics of bug repositories, Proceedings of the IEEE Conference on Software Maintenance, Reengineering and Reverse Engineering (CSMR-WCRE 2014) (2014). [7] C. A. Halverson, J. B. Ellis, C. Danis and W.A. Kellogg, Designing task visualizations to support the coordination of work in software development, Proceedings of the 20th anniversary conference on Computer supported cooperative work, (2006), pp [8] M. D Ambros, M. Lanza and M. Pinzger, "a bug s life": visualizing a bug database, Proceedings of the 4th IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT 2007), (2007), pp [9] P. Knab, M. Pinzger, B. Fluri and H. C. Gall, Interactive Views for Analyzing Problem Reports, Proceedings of the 25th International Conference on Software Maintenance (ICSM'09), (2009), pp [10] M. D'Ambros and M. Lanza, BugCrawle Visualizing Evolving Software Systems, Proceedings of the 11th European Conference on Software Maintenance and Reengineering, (2007), pp [11] A. Hora, N. Anquetil, S. Ducasse, M. Bhatti, C. Couto, M.T. Valente and J. Martins, Bug maps: A tool for the visual exploration and analysis of bugs, Proceedings of the IEEE 16th European Conference on Software Maintenance and Reengineering (CSMR 2012), (2012), pp [12] J. Gong and H. Zhang, BugMap: a topographic map of bugs, Proceedings of the 9th Joint Meeting on Foundations of Software Engineering, (2013), pp [13] M. Hammad and A. Rawashdeh, A Framework to Measure and Visualize Class Coupling, International Journal of Software Engineering and Its Applications, vol. 8, no. 4, (2014), pp [14] M. Pinzger, H. Gall, M. Fischer and M. Lanza, Visualizing multiple evolution metrics, Proceedings of the 2nd ACM Symposium on Software Visualization (SoftVis'05), (2005), pp [15] M. Fischer and H. Gall, Visualizing feature evolution of large-scale software based on problem and modification report data, Journal of Software Maintenance and Evolution: Research and Practice, vol. 16, no. 6, (2004), pp Authors Maen Hammad is an Assistant Professor in Software Engineering Department at The Hashemite University, Jordan. He completed his Ph.D. in Computer Science at Kent State University, USA in He received his Master in Computer Science from Al-Yarmouk University Jordan and his B.S. in Computer Science from The Hashemite University Jordan. His research interest is Software Engineering with focus on software evolution and maintenance, program comprehension and mining software repositories. 44 Copyright c 2014 SERSC

9 Somia Abufakher is a master student at the software engineering department, The Hahemite University, Jordan. She got her bachelor degree in Computer Science from Zarqa Private University, Jordan in Her research interest is in software engineering with focus on software maintenance. Mustafa Hammad is an Assistant Professor at Information Technology department in Mu tah University, Al Karak - Jordan. He received his PhD. in Computer Science from New Mexico State University, USA in He received his Master degree in Computer Science from Al-Balqa Applied University, Jordan in 2005 and his B.Sc. in Computer Science from The Hashemite University, Jordan in His research interest is Software Engineering with focus on static and dynamic analysis and software evolution. Copyright c 2014 SERSC 45

10 46 Copyright c 2014 SERSC