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:
IntranetNOTE: 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 youre 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.
1) You can find Remedy on our Network Neighborhood:
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) Youll be initially prompted for login and password. If youve 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) Youll 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 youre 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 dont 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.
3) Press the big yellow finger in the upper-left of the screen and youre 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 its 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. Its 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) Youll 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 Ive 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.
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
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.
Cant 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.