If a duplicate bug is detected, Bugzilla will then notify users and allow them to add themselves to the notification list for future updates on the bug. If users attempt to file a duplicate bug in the system, the software automatically checks for similar existing bugs based off of the previously submitted summary details. Users can also use the Bugzilla tool to assign a bug submission so they are notified of future changes to the report - like when a resolution to the bug is found.Īnother useful feature of the Bugzilla software is automatic duplicate detection. The spreadsheets provide options for basic information such as title, summary, description, status, severity and resolution, but they also allow for more detailed input such as product, component, version, operating system and keywords. The Bugzilla issue tracking system contains an interactive tracking spreadsheet that allows users to submit new bug reports or other data that requires tracking or updating. Additionally, collaboration and reporting features simplify defect tracking, reduce deployment delays and prevent app downtime. This can be done in both the predevelopment and post-development stages of the application. The software isn't designed to diagnose or repair developed applications however, users can categorize, track and detail debugging procedures - and other similar actions. Otherwise, the bug will have its status changed to the initial confirmed status for the bug.What features of the Bugzilla bug tracking tool support application testing? Because products can have different workflows, what happens if you change the product for a bug? If (everconfirmed = 0) for the bug, then the bug will have its status changed to the initial unconfirmed status for a bug. There is also one additional change to editproducts. If there are no bugs in a product then this is not needed and will be skipped. The user can then say "all bugs with status X in the old workflow should not be status Y in the new workflow". After selecting the new workflow to use, the user will be shown all of the statuses in the original workflow. When editing an existing product, the user will be able to change workflows. When creating a new product, the user will be asked to choose a workflow to use. To see the list of initial statuses for a new bug, search for bugs where "from_status IS NULL".Īll of this will mean a change to the editproducts CGI. If you search for all rows in the table matching a specific workflow and from_status, you will see all of the transitions that the bug can take. Each transition has a unique ID, and is part of a specific workflow. The first table, 'bug_transition', is hopefully straightforward. This will have two new tables, 'bug_transition' and 'transition_group_map': If a localized description does not exist, then it will fall back to the description in the database. Also, TT code will be written to allow status descriptions to be localized. It will take a bug ID or a product name, and will first confirm access to the bug/product before displaying anything. To be safe, the CGI will not take a workflow ID directly. The "Status" link on each bug's page will now point to a CGI that describes the different statuses available to the workflow. On the templates side of things, some changes will have to be made. An admin will be able to add/edit/delete statuses for any given workflow. On the web side of things, a new admin page will be created to provide access to edit a workflow. The description column gives us a description of the status. The workflow column is added, so we know which statuses are added to which workflows. The isactive column is gone (to stop using a status, simply don't allow any transitions to it). The id, sortkey, and value columns are as before. This bug has been fixed, and the fix has been verified. The list of statuses is relatively simple, and will be stored in a modified version of the bug_status table: So, what is a workflow? A workflow is, at its heart, a list of statuses and a graph of transitions. Products already existing will be using the default workflow. Each product can have a different workflow. New Bugzilla installations will be given a default workflow, and current installation will have the current list of statuses, combined with standard Bugzilla transitions, made into the default workflow (more on this soon). Each Bugzilla installation will have one or more workflows configured. The upcoming patch will open an existing, but relatively restricted concept, in Bugzilla: The workflow. OK, I have gone through everything and thought over this, and here's what I'd like to do:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |