Bug Tracking and Bugzilla

1. Bug Tracking and Bugzilla CS 420 – Software Engineering in Practice

2. Why we don’t like writing bugs… • It takes time…that we don’t think we have. • We already know the information; we are only writing about it for someone else. I’ll just tell him about it…or not. • We know we can fix it before the time it takes to write up the bug. So, why write up the bug? • Who really cares besides Orest? • The bug tracking system drives me nuts…I don’t understand it. • There’s no reason to draw attention to the problem. I should have caught it earlier. • I’m a developer; I’m supposed to be an introvert who likes to keep problems to myself.

3. That said…why enter bugs anyway? • You are part of team, and it serves as a means of communicating problems across team members. • Your bug may be one of many bugs that you and others don’t know about unless it is tracked. It may even be related to another already known problem.

4. That said…why enter bugs anyway? • Release management procedures may already be in place, which don’t take your bug or fix into account. A Help file change might be needed. • Someone else may know more about the priority of deferring or fixing the bug than you do. • A fix might require regression testing, which needs to be scheduled.

5. Why use a bug tracking tool? • Provides a history as to the effort and decisions involved with solving a particular problem. • Provides a means for tracking the status of the test and fix cycle. • Helps prioritize the development and QA effort.

6. Why use a bug tracking tool? • Serves as a repository for future enhancements to products. • Helps to assess the overall quality of a release candidate application. • It’s simply the intelligent thing to do!

7. Approaches to Bug Reporting • If the bug report is not clear and understandable, chances are that the bug report will be ignored. Take a moment to learn how to write an effective bug report. • Write problem reports immediately, as soon as you can. You are more likely to write an effective report.

8. Approaches to Bug Reporting (cont) • Team members are likely to dismiss reports of problems that they cannot see or reproduce. Take a moment to ensure the bug is reproducible. If you can’t reproduce it, indicate this. • Team members are more likely to postpone dealing with a bug report that looks long. Provide supporting evidence in the form of an attachment.

9. Approach to Bug Reporting (cont) • Check if the same bug already exists in the database. Someone else may have already reported it. Duplicates waste time and confuse the process. • Get familiar with the bugs logged against a project you are working on. Learn to run queries on the various bug data fields, and customize your views.

10. Approach to Bug Reporting (cont.) • A bug report that irritates the reader does not motivate him/her to fix it or verify it. Be respectful; focus on the problem, not the person. • Enter one bug per report. Multiple bugs can result in multiple resolutions which complicate the bug reporting process, when written as a single bug. • Don’t skip fields that are optional. They are meant to be optional only when they don’t apply to a particular problem.

11. How to enter a new bug Reporter: That will be you! It’s automatically filled in. Version: Options provided. Component: Options provided. Platform: Options provided. Operating System: Options provided. Severity: Options provided. Frequency: Options provided. Priority: Options provided.

12. How to enter a new bug Assigned To: Enter the email address of the team member to whom the bug should be assigned. If you do not fill out this field it will automatically be assigned to the default component owner. CC: Enter the email addresses of any team members you wish to give notice of the bug report. URL: Enter the URL for the application instance

13. How to enter a new bug Summary: Enter a concise statement that describes the problem. Remember that this field is used to find and review bugs. Make it as short and meaningful as possible. Steps to Reproduce/Description: Steps for describing the bug should be enumerated when appropriate. It makes it easier for the investigator to reproduce it, and it makes it possible for someone, other than the reporter, to verify the fix. Provide any useful comments or information that enhances the description. If you have a copy of the log file, a screen shot, or any other supporting documents include them as attachments. To include an attachment: Finish filling out the bug report and select ‘Commit’. The confirmation page which follows will include the ability to add attachments. However, once the bug is saved, you are free to return to the bug and add an attachment at any time. The attachment field will be visible.

14. Determining Severity/Frequency/Priority First, some definitions: • Severity: the impact or consequence of the bug to the end-user, an organization, third parties, a service, etc. • Frequency: the likelihood of the bug occurring or manifesting itself to the end-user, an organization, third parties, a service, etc. • Priority: the relative importance of addressing and resolving the bug • Given the above definitions, it is easy to see why the Priority would best be defined as a result of understanding the combination of both Severity and Frequency of a bug. • The Registry Team should review and agree upon the definitions and guidelines that follow.

15. Defining Severity Severity: the impact or consequence of the bug to the end-user, an organization, third parties, a service, etc. • Blocker • Critical • Major • Normal • Minor • Trivial • Enhancement

16. Severity - Blocker • Blocks development and/or testing work (new build, with fix, needed immediately)

17. Severity - Critical Critical: • Application crashes • Application or service does not work as intended; impossible to use the application or a main function of the application; critical functionality lost • Stored data corrupted • Conflicts with a high-priority (must-have) accepted requirement • Severe memory leak • Compromises Stanford’s standards or policy (e.g. security) • Help file is missing • Help file is incorrect and misleads the user

18. Severity - Major • Operation is significantly impacted • User is possibly lead to creating future problems • Conflicts with a medium-priority accepted requirement • Spelling or grammatical mistakes in the User Interface

19. Severity - Normal (Would like to see this changed to ‘Average’) • Loss of function, but there is a clear work-around • Unfriendly behavior that is hindering, but workable, for the user or service • Explanation of feature missing from Help File

20. Severity - Minor • Cosmetic problems in the UI, other than spelling and grammatical mistakes; i.e. font sizes, placement of controls (edit boxes, list boxes, etc.) that are not hindering • Unfriendly behavior that is merely annoying to the user • A problem of small impact to the user • Spelling or grammatical mistakes in the Help File

21. Severity – Trivial/Enhancement Trivial: (Remove: Redundant to Minor. We do not need this level of granularity.) • (Do not use – Use Minor instead) Enhancement: • Nice to have feature (not in scope) • Request for change

22. Severity • Severity is a required field. • By default, Bugzilla has ‘Normal’ selected on the new bug entry form. If this is not correct for the bug which is being entered, you should change it to the correct Severity. • If there are better ways to describe the severity of defects for applications that are background processes (i.e. the Regis apps and Slogs), then we should be sure to add those here.

23. Defining Frequency Frequency: the likelihood of the bug occurring or manifesting itself to the end-user, an organization, third parties, a service, etc. • Always: encountered at all time • Likely: will probably be encountered • Unlikely: will probably not be encountered

24. Frequency • Determining Frequency can get confusing considering that ‘likelihood of occurrence’ can be applied to ‘all users’ or a ‘single user’. • Frequency is a required field. • By default, Bugzilla has ‘Likely’ selected on the new bug entry form. If this is not correct for the bug which is being entered, you should change it to the correct Frequency. • Frequency should be determined by those who have the knowledge to do so. However, you should make an educated, or uneducated, guess.

25. Defining Priority Priority: the relative importance of addressing and resolving the defect • P1: Resolve Immediately • P2: Give High Attention • P3: Normal Queue • P4: Low Priority • P5: Waiting Priority (not in scope or significant enough to be prioritized)

26. Defining Priority