Summary
This article first introduces the general process of Bug management, then analyzes the characteristics of the bug tracking and management system applied to the open-source software development process, and describes a typical bug lifecycle process, and explained the completion of a qualified bug report. Article It also briefly introduces popular defect tracking and management systems such as Bugzilla, and gives personal ideas.
Keywords: Bug Management, lifecycle, defect tracking and management system
Abstract-This paper introduces a normal Bug management process, analyzes characteristics of bug tracking and management in development of open source software, describes a classic bug life cycle, and explains how to accomplish an eligble bug report. also, some popular bug tracking and management systems such as Bugzilla are introduced, following with some personal thoughts.
Key words: Bug Management, life cycle, bug tracking and management system
1Problem description
In the process of software development and maintenance, effective quality control and assurance work is particularly important. Because of this, software defect tracking and management has become an important aspect of quality control and assurance in the modern software process. Defects (defect or bug) in software are a "by-product" in software development ". In general, defects may cause software products to be unable to meet users' needs to some extent [ [1] ]. The open-source software organization claims that the purpose of open-source is to achieve better quality, higher reliability, higher flexibility, low costs, and the end of the interception of prey-type sellers [ [2] ]. As said, the spirit of open source software freedom and openness has ushered in some advocates. However, Software defects always exist. How can we track and manage open-source software bugs? What is the difference between it and commercial software defect management? What bug tracking systems are open source users using? With questions and puzzles, I began to discuss bug tracking and management for open-source software.
2 bugTracking and open-source softwareBugManagement
2.1 General defect management process
Software is not perfect. Under normal circumstances, annoying bugs cannot be the expectation of software engineers. Defect tracking management is an important part of testing. The purpose of testing is to detect defects in the software system as soon as possible, ensuring that each detected defect can be promptly handled is an important part of the test [ [3] ]. No one wants their products to have too many defects, but since there are defects, they should be tracked and managed. Before introducing open source software defect tracking and management, we need to have a systematic understanding of the general defect management process.
Software errors (bugs) are generally found during the test. How to handle the errors found during the test will directly affect the test results. For bugs found in the test, a clear management process is required. First, the tester submits a new bug to the database and the error status is new. Then, the senior tester verifies the error. If it is confirmed that it is an error, assign it to the corresponding developer and set the status to open; if it is not an error, it is rejected and set to declined state. Then, the developer queries the bug in open state. If it is not an error, the status is declined; if it is a bug, the fix status is fixed. For bugs that cannot be solved, leave a text description and keep the bug open. However, developers cannot decide the bugs that cannot be solved or solved by extension, A meeting (Review Meeting) is generally accepted. Finally, the tester queries the bug whose status is fixed and then verifies whether the bug has been resolved. For example, if the status of the bug is resolved to closed, if the status of the bug is not resolved to reopen [ [4] ]. In this process, we can find that it has high requirements on testers. For example, it should not be treated as a bug for problems that may not be wrong.
2.2Open Source Software Bug Management
Compared with the conventional Bug management process, defect tracking and management of open-source software cannot surpass it. However, as we have mentioned, the particularity of the open-source software development model also puts forward more stringent process requirements for its bug tracking and management process. First, it is necessary to have a correct understanding of the Bug Tracking System (bug tracker. Defects include product errors, requirements and design changes, new features or extensions (new feature, enhancement), which exist throughout the entire software development lifecycle [ [5] ]. So what information does a bug tracker need to save? Bug Tracking systems are often used to record new functional requirements, task logs, and patch packages during software development. As long as they have a clear starting and ending state, they and the changes and generated information in this process should be stored in the system. Compared with the commercial software development process, in the open-source software development process, the typical life cycle of a bug is as follows: the problem Reporter (may have no idea about the project) summarizes the problems that arise, give an appropriate initial description, archive the information, and submit it to the system. Other users or testers may give further comments when reading the bug information, in this process, the archive may be asked to clarify some problems in an appropriate way. The problem occurs again in other user experience processes. Repeated reproduction indicates that the problem exists, this process is actually an important stage in the life cycle of a bug, because an unrealistic bug may be closed or deleted at this stage; the problem or defect is diagnosed, the cost of solving the problem also has been estimated. This process may be completed by developers, but it may also be enthusiastic users. The time for solving the problem has been preliminarily planned, the problem may be solved in a certain version but not necessarily in the next version. Finally, the problem is solved. After the relevant changes are recorded, the problem should be closed.
However, the above process may stop midway through. So why is a bug aborted? In fact, the bug reporter may be unfamiliar with projects or software products, so that he may submit an error report. In this way, the bug may be quickly disabled. Another factor is that the same problem has been recorded in the system and may even be solved. In this case, the redundant bug will be deleted. Of course, the developer may think that a bug does not exist at all, or the developer simply changes some places and thinks that the bug no longer exists, so he may turn off the unsolved problem [ [6] ].
2.3BugReport
Technical support is considered a terrible task because of poor bug reports that need to be handled [ [7] ]. We can see that when a problem or defect occurs, the system may receive reports from many users and testers. How can we effectively implement bug tracker?
After an open-source project is started, the bug tracking system starts to run normally on servers in the C/S or B/S architecture. On the client side, it provides one or more user interfaces, such as web forms and emails. Some defect tracking systems also provide some submission tools to simplify user operations. First, let's focus on the client-specific interfaces. For example, if a tester wants to report a bug, he first enters the bug report interface. But more often, the system always prompts the tester to pay attention to the issues. In fact, the most important thing before reporting a bug is to discover the bug and try to find out the cause. Just as new Linux users may be told: try to pay attention to the current problem and try to find out the cause [ [8] ]. A friendly bug reporter should not only know the complaints. In the report, the annoying window pops up. If such a report produces ambiguity, how can we submit a qualified bug report? Elisabeth Hendrickson wrote in his book: When you write a bug report, remember your audience, select a good title, clearly record steps, and explain the impact of errors; your bug report will be better because of your extra efforts and more bugs are fixed; in the end, we will achieve the expected results-make the error fixed before it hurts the user [ [9] ]. Mozilla, a well-known open-source software quality control and assurance platform, stipulates that a good bug report should contain the following information: Software Version serial number, operating environment, error site information, debugging and warning information [ [10] ]. In practice, it is necessary for the defect Tracking System to provide appropriate interfaces to users.
Bug tracker Introduction
In the open-source software field, there are many bugs tracker, and the famous ones include Bugzilla, gnats, buggit, Mantis, and dbts. These defect tracking and management systems provide a good way to control open source software management. Software development requires the existence of bug tracker, and the development of open-source software is even more inseparable from them. Liu zhenfei, the initiator of the open-source bug tracker bugfree at Microsoft, said: among all (Microsoft) tools, what I admire most is its Bug Management System RAID (now called product studio). The value of raid is that it closely tracks the actual bug status of the current product, enable members of the project team to effectively coordinate their work [ [11] ].
Similarly, open-source software does not support suitable Bug management software, and it may be difficult to develop excellent products. Below we can understand some mainstream systems in this field. The buzilla provided by Mozilla is a product defect record and tracking tool that can build a complete BUG Tracking System for you, it consists of four parts: reporting bugs, querying bug records and generating reports, processing and solving, administrator system initialization, and setting. It has the following features: web-based, easy to install, fast to run, and secure to manage. It is conducive to clearly communicating defects. The system is flexible and powerful with configurable capabilities. It supports automatic email sending [ [12] . In contrast, Mantis is a PHP/MySQL/Web-based defect tracking system. It has the personal email notification function, supports multiple projects, multiple languages, and other advantages [ [13] ]. In addition, online bug tracking and management systems such as trackstudio and bugols provide excellent user interfaces. Specifically, bugols declares on its home page that their ideal is to make every Program Developers can easily release and maintain their own programs. Their mission is to build the world's most convenient, easy-to-use, and user-friendly online Bug management tools with superb technology [ [14] ].]
However, most defect tracking systems seem to focus too much on how to manage bugs, but ignore the effective combination with automated quality evaluation tools. On the other hand, many researchers try to use open-source projects Source code Design new project quality evaluation tools with the ease of test data [ [15] ]. Maybe they can spend more time designing bug tracking and management systems.
4Conclusion
After introducing the knowledge of bug tracking and management, this article analyzes the tracking and defect management of open source software. The study found that it is important to submit a friendly bug report to the bug tracker to solve the problem in a timely, effective, and correct manner. However, most web-based bug tracker provides a detailed blank bug list on the client for users to fill in. Although this method is convenient for the system to effectively accept and handle bugs,
However, it ignores whether rich and complex forms exceed the limit that the bug reporter can afford. Of course, these systems adopt some drop-down lists to select items, but too many users must perform the operation is not satisfactory. In addition, the interfaces of these systems are not very beautiful. When a non-professional person reports a bug, the unfriendly interface may cause him to give up reporting a possibly fatal bug. The solution is to select a balance between required information and additional information, and provide a clean interface. Another problem is that most bug trackers reject repeated bugs. However, the bug type, report time, and report frequency are important evaluation parameters [[16] ]. In this way, if the system rejects repeated bugs, it may be difficult to count the frequency of occurrence of a bug.
In practice, it is found that most bug trackers can filter bug reports to prevent repeated reports or existing problem reports, some systems can also fully accept reports submitted by E-mail or coordinate work with the mail list. However, the filtering mechanism is actually a skill and excellent Algorithm . Imagine a problem report submitted by a report subject that is inconsistent with the problem description in the report. What is the result? This may be an important report, but the reporter neglected to make a mistake, but the system rejected it as an existing simple error. This is the problem. The next version of the project may fail due to the bug, and the consequences may be very serious. In fact, the question to be pointed out here is how to effectively and accurately filter bug reports? In fact, some search and matching technologies are involved here. The system should not only check the bug subject, but also its internal information. How to implement it efficiently? This is a confusing and Close topic. Maybe we can look forward to the progress of machine learning theory and application. When the system is quite intelligent, we may be able to quickly catch possible bugs and automatically modify possible errors, make a bug report complete, consistent, and accurate. In this case, the running of a bug tracker will be more effective and may play an important role in the development of open-source software.
Thank you
During the study, our team members had a good communication and exchange, exchanged views on some issues, and formed a good team atmosphere. At the same time, I would like to thank * instructors for their guidance and help.
References
[1]Liu Yin. <software defect management>. xisai network, 2005.
[[2]] Http://www.opensource.org/
[[3]]Guanhe District.<Defect Tracking Management>. OnHttp://www.testage.net/TestTech/BugM/200601/120.htm 2006.
[[4]]Cui Qiliang. <general process of Bug Management>. http://www.51testing.com/html/34/1275.html, 2006.
[[5]]Cai Jing. <successful practices of defect tracking using open source software mantis>. perworks/CN/Linux/software_engineering/L-Mantis/index.html "> http://www-128.ibm.com/developerworks/cn/linux/software_engineering/l-mantis/index.html, 2003.
[[6]] KARL Fogel. Producing Open Source Software: bug tracker. O' Reilly, 2005.
[[7]Http://www.cndw.com/tech/php/2006041847238.asp
[[8]]Found bug. On http://kernelnewbies.org/FoundBug
[[9]] Elisabeth hendricksoTranslation. Writing into tive bug reports. On http://www.51testing.com/html/34/67.html, 2005.
[[10]] Chrisyeh. How to write a good bug report. http://www.mozilla.org/bugs/bug-reporting.html
[[11]]Liu zhenfei. Experiences and practices of Bug management. On http://bugfree.newsky.cn/zhenfei/Document/BugFree.htm.
[[12]]Xu yixiao. Introduction to the test tracking tool Bugzilla.
On http://www.csai.cn.
[[13]]Same [5].
[[14]] Bugols. On http://www.bugols.com.
[[15]] Georgios gousios, Vassilios karakoidas, Konstantinos stroggylos, Panagiotis louridas, vasileios vlachos, and diomidis SPINELLIS. Software Quality Assessment of Open Source Software. New technologies publications, 2007.
[ [16] ] Adriaan de groot1, Sebastian K? ugler1, Paul J. adams2, and Giorgos gousios3. call for quality: Open Source Software Quality observation. the Second International Conference on open source systems, 2006. Note: Please indicate the source of your opinion when referencing this article
