Maybe you have not yet seen the value of an error management system; maybe you are overwhelmed by a large amount of test data, and urgently need a good helper to record and track product defects; maybe you are constantly developing and improving an Error Tracking System through various methods such as workbooks and databases. Mozilla provides us with a shared free tool, buzilla. as a product defect record and tracking tool, it can establish a complete BUG Tracking System for you, it consists of four parts: reporting bugs, querying bug records and generating reports, handling and solving, administrator system initialization, and setting. And has the following features: 1. Web-based, easy to install, easy to run, and secure to manage. 2. It is conducive to clearly communicating defects. The system uses databases for management, provides comprehensive and detailed report input items, and generates standardized bug reports. Provides a large number of analysis options and powerful query matching capabilities, and supports bug statistics based on combinations of various conditions. When an error changes in its lifecycle, developers, testers, and management personnel will obtain dynamic change information in a timely manner, allowing you to obtain historical records, refer to this record when checking the error status. 3. The system is flexible and powerful in configuration. The buzilla tool can set different modules for software products and set developers and testers for different modules. This allows the tool to automatically send reports to specified owners; you can set different groups and divide permissions. You can set different permissions for different users to manage the bug records. Different levels of severity and priority can be set to manage errors in the error lifecycle, from the initial report to the Final Solution, ensuring that errors are not ignored, at the same time, you can focus on errors with high priority and severity. 4. Send email automatically to notify relevant personnel. The latest dynamic information is automatically sent based on the specified owners to help testers communicate with developers effectively. The following describes how to use the tool according to the bugzilla operation instructions and the bugzilla administrator operation guide. I have a lot of opinions in this article from my personal experience. If you have any mistakes, please be sure to make an axe. Bugzilla operation instructions 1. User logon and settings 1.1 User Logon 1. Enter the server address http: // 192.168.1.6/Bugzilla /. 2. on the homepage, click forget the currently stored login, and then click Login. 3. Go to the registration page and enter the user name and password to log on. The username is the email address, and the initial password is the abbreviation of the username. 4. If you forget the password, enter the user name, click [submit request], and reset the password Based on the received email. 1.2 Change Password and settings 1. After logging on to login, choose edit prefs> accout settings to change the password. 2. Choose edit prefs> email settings to set the email. 3. Choose edit prefs> permissions to query permissions. 2. Bug handling process 2.1 report bugs 2.1.1 testers report bugs 1. please first query and confirm that the bug report to be submitted does not exist in the original record. if it already exists, do not submit it. If you have any suggestions, add comments to the original record, inform the owner of the bug so that the owner of the bug can see this and modify it on his own. 2. If the bug does not exist, create a valid bug report and submit it. 3. Operation: click New, select a product, and enter the following table. 4. Note: if the value of assigned to is null, the default value is the specified owner, which can be manually specified. Cc: It can be separated by commas. Desription: 1) Steps for discovering problems 2) what happens after the above steps are executed. 3) expected correct results. Select group settings to restrict the permissions of this bug on the group. If this parameter is set to null, the permission is published. 5. Operation Result: You can select "new" or "unconfirmed" as the initial state for the bug status. The system will automatically notify the project leader by email or directly notify the developer. 6. Help: Bug Writing Guidelines 2.1.2 developers report bugs. 1. The specific method is the same as that reported by the tester. 2. difference: the initial status of the bug is automatically set to unconfirmed and changed to "new" after the tester confirms ". 2.2 different bug handling situations 2.2.1 after the owner of the Bug handles the problem, the author puts forward suggestions and solutions. 1. provide a solution, enter additional comments, and create attachments (for example, change the submission form) 2. perform the following operations) 3. Note: The problem described by fixed has been modified. The problem described by invalid is not a bug (this item is used to cancel an incorrect input) The problem described by wontfix will never be fixed. The problems described by later will not be solved in the product version. The problem described by duplicate is a duplicate of an existing bug. All worksforme attempts to recreate this bug are invalid. If more information appears, re-allocate the bug and archive it. 2.2.2 the project leader or developer re-specifies the owner of the bug. (Owner) 1. This bug does not belong to its own scope. You can set it to assigned and wait for the tester to re-specify it. 2. This bug does not belong to its own scope, but it knows who should be responsible and directly enters the email of the specified person for ressigned. 3. Operation: (optional) * Accept bug (change status to assigned) * Reassign bug * Reassign bug to owner and QA contact of selected component 4. Operation Result: the bug status changes to New again, and the owner of the Bug changes to the specified person. 2.2.3 The tester verifies the modified bug. 1. The tester queries the bug that the developer has modified, that is, the status is "resolved", and the resolution is "fixed. (You can create a test case attachment) 2. After verification, modify resolution to verified. After the entire product is released, change it to closed. If any problem persists, reopened the status changes to "new" and send an email notification. 3. Specific operations (optional) 1. Leave as resolved fixed 2. Reopen bug 3. Mark bug as verified 4. Mark bug as closed 2.2.4 bug reporter or other users with permissions to modify and supplement bugs 1. You can modify the content of a bug. 2. You can add attachments, Add relevance, and add comments to explain what you are doing and why you are doing it. 3. operation Result: when some people modify the bug report or add a comment, they will be added to the CC list, changes in the bug report are displayed in an email to the owner, writer, and CC list. 2.2.5 The tester confirms whether the bug reported by the developer exists. 1. query bugs in the "unconfirmed" status, 2. The tester confirms the bugs submitted by the developer and confirms that the bugs exist. 3. Specific Operation: Select "Confirm bug (change status to new)" and perform commit. 4. Operation Result: The status changes to "new ". 2.3. query bugs 1. directly enter the Bug ID and click find to query. You can view the activity records of bugs. 2. Click query and enter the conditions for query. 3. query the bug activity history 4. Generate Reports. 5. Help: Click clue. 3. Permission description 1. The group members have the right to query bugs, but cannot modify them. 2. The owner and reporter of the bug have the right to modify. 3. users with special permissions have the right to modify. 4. Bug handling process 1. When a tester or developer discovers a bug, they can determine the module where the problem belongs. after entering the bug report, they can notify the project leader by email or directly notify the developer. 2. The project leader re-assigns reassigned to the developer of the Bug based on the actual situation. 3. After receiving the email information, the developer determines whether the modification scope is correct. 1) if not, re-reassigned the assignment to the project leader or the developer to be assigned. 2) If so, resolved and provide a solution. (Patch attachments and supplemental instructions can be created) 4. The tester queries the bugs that have been modified by the developer and retests them. (You can create a test case attachment) 1) after verification, the status is changed to verified. After the entire product is released, change it to closed. 2) There is still a problem, reopened, the status changes to "new", and send an email notification. 5. If the bug has not been handled in a week. Bugzilla will always harass its owner by email until it takes action. 5. Life Cycle of a bug
Bugzilla administrator operation guide 1. Main work content: 1. 1 define product, version, and component, and specify the corresponding developer and QA contact of the module ). 1.2 Definition and division of groups 1.3 definition of bug severity and priority during testing Add users and set group and permissions for all users. Parameter settings 1) urlbase: Enter the IP address of the server where the bugzilla tool is located. 2) usebuggroupsentry: Set to on and can be grouped. 3) whinedays: If the bug is not handled within the period set by whinedays, the mail will be automatically resend. The default value is 7 days. 4) defaultpriority: sets the default priority. 5) commentonresolve: if it is set to on, the system will force the developer to fill in the modified content after handling the bug. 2. Basic operations: 2.1 create a default administrator user. Run checksetup. pl. If you accidentally delete the administrator, run checksetup. pl again. 2.2 Manage Users 2.1 new users added Click Users in the lower-right corner of the page, and after submit, the Add new user page appears. Enter the corresponding input. Login Name: Generally, it is the email address and can be set as another identifier. 2.2 forbid a user Enter the disabled text input box. 2.3 modify a user You can modify the user registration name and password. Set permissions QA permissions are generally set to canconfirm and editbugs. Developer permissions: None Group Control: Group 3. Manage a group 3. 1. Add Group Edit Group à add groups (new user Regexp can be left blank/select active)-> Add 3.2 modify group and submit. 4. Manage product and Component A) add product B) component corresponds to one owner (fixed) and QA contact (fixed) C) component number of unconfirmed = 10000. This product selects the initial bug status (unconfirmed, new) |