By Jos Claerbout
Welcome to the world of BugFlash – the tool that we, the Web Development Team, will use to track and check bugs, as well as keep project status.
First and foremost, you will need a username and password for Remedy. If you do not have one already set-up, please contact Ricardo
Categorizing bugs is an important first step to tracking bugs properly. In BugFlash we use one general area for all bugs ###### Under this general area there are specific sites that the Team is working on. The categories you will find are:
Internet
Intranet
NOTE: Due to a recent transition in Bugflash you may see duplicates. These will be cleaned up so that the categories mentioned above will be our standing categories.Bugflash is a schema (front end) in the Remedy application that allows anyone within our company to modify and access a common database. It is used extensively by Engineering and QA; Customer Care uses a slightly modified version to handle customer issues.
The Web Development team has decided to adopt Bugflash in order to track the many bugs that people find and requests that they file for changes to Web sites. After taking a few minutes to familiarize yourself with the application, you will find Bugflash a simple and effective way to request, document, and track changes made to Web pages.
If you’re reading this document, you should have a remedy logon and password already. If you do not have a Remedy logon (or have forgotten it), contact John at the Helpdesk, x7800. You will need a Remedy logon in order to file bugs.
Brief Contents:
1) You can find Remedy on our Network Neighborhood:
\\webtv-nt\Software\Other\Remedy\3.2 Client
2) Double click the “arswut.exe” file.
3) Install to your preference; I generally just take whatever it recommends.
4) When prompted for your Remedy Server Location, enter “remedy-server-1”
5) That should do it.
1) Open up your new “aruser.exe” file.
2) You’ll be initially prompted for login and password. If you’ve forgotten these, contact John at the Helpdesk.
3) On the top menu bar, select “File – Open Submit”. This will allow you to submit bugs; selecting “File – Open Query” would allow you to search for them.
4) You’ll be given a choice of many schemas. The one you want is called “QA-Bugflash”
5) Double click to select it.
Before you get concerned about the two dozen or so fields that have just popped up on your screen, rest assured you’re only going to need to know about maybe 5 – 10 of them. Most of the rest are self explanatory, and if you choose, you can just hide those you don’t like.
While you can file bugs against many parts of the WebTV service using Bugflash, we have set up special categories for Web sites maintained by the Web Development Team. These categories are:
Publications – websites – extranet
Publications – websites – internet
Publications – websites – intranet
Each breaks down further and highlights specific ongoing projects. If your project is not listed, please use the “other” category.
If you find a bug (typo, broken link, etc) on one of these pages, you can file a bug using the following steps:
1) Select “File – Open Submit” QA-Bugflash.
2) You will need to fill in the following fields:
· Problem Synopsis – A one line description of the problem.
· Category – Use the menus to select Publications – Websites – XXXX - The name of the developer responsible will pop up in the “responsible field”
· State – Leave this blank, or select “Pending”.
· Severity – Mark according to how important you think the bug is.
· Detailed Problem Description - If there is any ambiguity, your bug may not be fixed properly.
· URL – Make sure you include this.
· Notification List – Any name separated by a space will be mailed to XXX AT corp.webtv.net. To notify all of WebDevFolk, enter asdf AT microsoft.com into this field.
3) Press the big yellow finger in the upper-left of the screen and you’re in business! Both the submitter and the responsible developer will receive emails letting each know that a bug has been filed.
The submitter, the responsible developer, and anyone on the notification list will receive an email when the bug is submitted, and each time it changes states after that.
If you are one of the primary developers (John, Rosemary, Jos), you will use the steps below to address a submitted bug. However, bugs will be frequently assigned to other members of the team, for QA, investigation, or more information, so it’s important that we all know how to modify individual bugs.
1) Select “File – Open Query” QA-Bugflash
2) Note that the background color is blue, instead of light green. It’s pretty.
3) You can search for bugs using any of the fields on this page. The most common search is either by Bug Number (in the upper left corner), or “Responsible” (just two fields below Bug Number)
4) After you have written a search parameter in one of the fields, select the “Query – List” function.
5) A number of bugs will appear. Highlight the one you wish, the select “Query – Modify Individual”.
6) You’ll be brought to the green “submit” window, and allowed to modify the bug. Put all information in the dialog box, change whatever else you wish, then press the yellow finger to submit.
This gets a bit involved, but I’ve tried to keep it as simple as I can. If you think the process could be improved, please let me know.
1) Bug gets filed. Status - Pending
2) After some hemming and hawing, developer opens bug. Status – Open
3) Developer fixes bug in the development area and assigns bug to the submitter to verify (or someone else in the group if developer was the submitter). Status – Fixed
4) Submitter looks at bug, and assigns to “Built”, if fixed. If not fixed, submitter returns bug to “pending”, and assigns back to developer.
5) Rosemary, on a regular basis, will move the “Built” content from the development server to the staging server. Status – Staged.
6) Content will roll to live site on regular schedule (Rosemary or Jos take care of this part).
7) The primary developer for any given bug will close staged bugs once verified in production.
<![endif]>
The "State" field of Bugflash can be the most confusing to those not initiated in its ways. Because the states were primarily designed with Engineering in mind, they will not map perfectly to the issues of publication website bugs, but it will be pretty close. An “active” bug is one that requires attention; and “inactive” one is a bug that no one cares about. Here is how we plan to use the various Bugflash states:
Pending: Unless you filing a bug against something for which you are responsible, you should always file it in "pending" first. This basically means that you *think* it's a bug, and are waiting for confirmation from the responsible party.
Open: If the "responsible" party decides that the bug is *indeed* a bug, it will be put into "open".
Investigate: If the responsible party at any point has some questions best answered by someone else, she can put the bug into "investigate" and assign it to that person. Bugs filed without sufficient information frequently end up in “investigate” back to the submitter.
Fixed: The problem has been fixed on the development server or area (can be skipped if no development area exists)
Built: Once a bug has been verified fixed, it will be moved to “built”.
Staged: The bug has been fixed and that fix has been rolled to the staging server.
UI-Review: This state will not be used.
Used by Engineering if Usability is supposed to review a particular
bug fix.
Postponed: Person responsible realizes it's a bug, but it will not be fixed any time soon. Example: "The colors on the Corp. page make it hard to read". Postponed bugs should be reviewed and possibly re-assigned after every release.
A bug is "Not Active" if it is in any of the following states:
Closed: The fix has been rolled out to the live server.
Duplicate: If the responsible person determines that a bug is really a duplicate of a bug filed earlier, she should mark the more recent bug as "duplicate", and reference the original bug in the "Duplicate Of" field in Bugflash.
NAB: Not A Bug. Example "There are frames on the developer site!" This is a design decision, not a bug. Hence, this bug would be NAB'ed. A request to remove the frames from developer.webtv.net is really a "feature request", and such a bug should have the "feature request" radio button in Bugflash selected before filing.
Unsolved: The problem was seen once, but never seen again.
WillNotFix: The most controversial of all; the developer acknowledges the bug, but refuses to fix it.
How do I submit feature requests?
Although it might not sound like it, Bugflash is equipped to handle feature requests. When filing a feature request (“I think we should use more colors!”), make sure to check the “Feature Request?” radio button when submitting the bug. This will reduce the chance of your request being misunderstood.
Can’t I simply double click on a bug in a query list in order to modify it?
The default setting of Bugflash is to give you a “locked” version of the bug when you double-click it from the query list. To change this, select “File-Preferences”, then the “Query” tab. Under the “Double Click on a Query List Item”, select the “Open Modify Window” radio button.
How can I use the Web version of Bugflash?
Should you find yourself to be particularly masochistic, you can use the Web version of Bugflash found on our intranet. All you need is your regular Remedy logon and password.
How can I hide the fields I never use?
Once you get cocky, you may want to start customizing your Bugflash screen. This is easy to do. Select “Actions – Customize View”, then “QA-Bugflash”. You will see the Bugflash window on a grid. Click and drag any of the fields to your preference.
Does Remedy run on Win98?
Yes, but you may need to do a little work first. Download winsock.dll version 4.10 for Windows 98 if you try to run Remedy 3.2 on Windows 98 and get a "can not find server" error.
This document is a work in progress, crazy-ass HTML generated my MS Word. Please contact Jos Claerbout (x7824, josc AT corp.webtv.net) with any questions.