Improving Bugzilla's Flexibility to Satisfy QA Needs

QA Fields

How should Steps to Reproduce, Expected Results, and Actual Results be handled?

Four related widgets: If someone wants to update the steps to reproduce, they'd click the link by steps to reproduce and be scrolled to the comment where the current steps are, they could then copy the steps to the comment area and change the

How should Release Notes have been handled?

Just create a flag.

How should functionality have been handled?

Use keywords, e.g. auc (AutoUpdate Client), aus (AutoUpdate Server), db (DataBase), ....

How should Build Tested/Verified be handled?

For each build, file a set of bugs:
  1. Summary: "[Build Number] Known Issues", Alias: b#
  2. Summary: "[Build Number] Passed", Alias: b#-passed
  3. Summary: "[Build Number] Resolved Bugs", Alias: b#-resolved
  4. Summary: "[Build Number] Verified Bugs", Alias: b#-verified People will reference these bugs by their standardized aliases. These bugs will be marked as blocking individual bugs with the corresponding listed relation.

Where should related use case be stored?

In the URL field.

How should the source category be handled?

Instead of having a source field, people who need to file bugs from other sources should be granted "impersonation" permissions for those people.

New Bugzilla Features

How many big new features do I think we need?

  • Impersonation/Delegation.

    What is Impersonation?

    Impersonation is the ability to take an action on behalf of someone else.

    What is Delegation?

    Delegation is the act of granting another account the ability to impersonate your account.

    How would Impersonation work when filing new bugs?

    The enter bug form would allow you to change the Reporter field to anyone who has delegated permission for you to impersonate them. If a bug is filed with the reporter field marked as someone other than the logged in user, then when the bug is filed, the last action will be to change the reporter value from the logged in user to the impersonated user.

    How would Impersonation work when making a comment?

    The line containing the [ Commit ] button will be followed by an unchecked checkbox labeled "impersonating" followed by a drop down listbox (default of ---) containing all the accounts which have delegated impersonation to the logged in user. So it should look like this:
    [ Commit ] [ ] impersonating [---         |v]
    
    The requirement of checking the checkbox is to prevent users from accidentally triggering impersonation. processbug should complain if the impersonee field is changed from --- and the impersonating checkbox was not set.

    How would Impersonation Activity appear in the Activity Log?

    Who		When			What  	Removed		Added
    customer	2005-02-01 00:00 PST	UserID	qauser		customer
    customer	2005-02-01 00:00 PST	OS	other		Windows XP
    

    What are some examples of how people could user Impersonation/Delegation?

    1. Imagine a role based organization with users "sharon@qa.company.com" and "john@qa.company.com". Suppose john moves from qa to eng, he creates a new account "john@eng.company.com" and as "john@qa.company.com" he delegates all to "john@eng.company.com". He then no longer needs to log into his qa account, but sharon can search for bugs reported by qa by searching for reporter contains @qa.company.com.
    2. Imagine a company which wants to track reports from customers but doesn't want to give them accounts. The admin creates accounts "ibm@customer.company.com", "acme@customer.company.com", etc. and delegates all to the support lead "mark@support.company.com". Because mark is designated as having full delegation support, he can impersonate say "acme@customer.company.com" and add another delegate "lee@support.company.com" with report and change bugs. Lee will not be able to change acme's preferences or add delegtes, but that's ok, Lee's job will be as the point contact for ACME Widgets, a new small customer of Company.com. To search for bugs reported by customers, just search for reporter contains customer.company.com.
    3. You're in a bug triaging meeting and there's a chief note taker. There are five of you, and the note taker is going to update bugzilla after the meeting based on what the five of you said. In today's world, the note taker would write a silly comment like ben said blah. With delegation, each person attending the meeting adds the notetaker as a delegate for report and change bugs. It's best to do this before the meeting. When the notetaker goes to use bugzilla, the notetaker logs in normally, but makes changes by impersonating the person who was listed as indicating what should be done. When someone reads the bug, it will sound like the person who spoke in the meeting spoke in the bug. You can still find the note taker by checking the activity log, but in general what people want to see is who should be credited / blamed.
    4. You have a tendency to visit another person's computer while they're logged into bugzilla, and instead of logging them out you normally just write a comment like "(who you really are) whatever you want to say". You trust your colleague. You trust bugzilla's activity log to record impersonation and times accurately. A better way is to delegate limited permissions (probably just change bugs) to your colleague, and then when you use his browser session, you simply check the impersonate box and select your account from the list.
    5. You have multiple bugzilla accounts because of bugmail arrangements (I have three). You try very hard to always file bugs and comment under a single account. The only thing you use the other accounts for is to change preferences. Occasionally, you accidentally forget that you last logged into one of those accounts, and accidentally file a bug or comment in a bug under the wrong account. With delegation, all you have to do is delegate change preferences to your primary account, and then when you go to the edit preferences page, it gives you a drop down from which you can select any of the other accounts which have delegated preference control to you.

    How Would this Look?

    An example bug entry form (<enter_bug.html>), an example bug (<show_bug.html>), an example bug activity (<show_activity.html>), and the query page (<query.html>).