DRAFT. Standard Procurement System Bugzilla (SPS-B) Training Manual. Version 1.2

Transcription

1 Standard Procurement System Bugzilla (SPS-B) Training Manual Version February 2006

2 TABLE OF CONTENTS: 1.0 Overview Opening SPS Bugzilla Create a New Account Log In and Log Out of System Querying the Database Create New Issue Edit/Update Issue Test Site Managers Reports Scoring User Preferences 35 TABLE OF FIGURES: 2.1 SPS GTF Homepage Training SPS Bugzilla Welcome Page Create New Account Successful Account Creation Log In Log Out Query Page Results Window Results Window Long Format Enter Issue Page Successful Submission Edit Page Create New Attachment Reports Scoring Conference Results Issue Counts Issues Scored Edit Page of Scored Issue Scoring Module User Preferences Account Settings User Preferences Settings User Preferences Page Footer User Preferences Permissions 37 TABLE OF TABLES: 6.1 Enter Issue Fields General Information 24 i

3 1.0 Overview The Government Test Facility (GTF) uses a software package called Standard Procurement System Bugzilla (SPS-B) to track and monitor issues discovered during testing of the SPS product suite. SPS-B is a web-based application. It was developed from an open source application called Bugzilla, which was developed by Netscape Communications. Such companies as IBM, NASA, and DARPA track problems in their software development efforts using Bugzilla. This software has been modified to meet the needs of the GTF. This application has been used by the GTF since June This documentation is meant as a detailed instructional guide on how to use this software. It will provide descriptions, screen shots, and detailed instructions. This information is intended for every user of the software. 1

4 2.0 Open SPS Bugzilla To access SPS-B, open your web browser. SPS-B is compatible with a variety of web browsers including, but not limited to Internet Explorer, Netscape, Mozilla, and Firefox. When the browser has opened, in the address box, type in This will open the SPS Government Test Facility (GTF) web page see Figure 2.1. This page contains two links, one for the Training (A) system and one for the Production (B) system. The user will select which system to connect to. It is highly recommended that users create at least one issue in the test system prior to logging into the production system. Figure 2.1 SPS GTF Homepage A B 2

5 The remainder of this document is written for use with the training version of SPS-B. The users will notice only small differences between the training and production systems. Figure 2.2: Welcome Page displays the opening page of the SPS-B. Each user of the production system must have a training account or the production account will be disabled. Once the user has logged into SPS-B, the user is able to view reports, create a new issue, or query/update existing issues. To help the user, after logging in, at the bottom of each page there is a Navigation Bar. This bar provides quick access to each of the SPS-B sections and the user s preferences. Figure 2.2 Welcome Page 3

6 3.0 Create New Account A user account must be created to be able to access any data in SPS-B. The account controls access to various parts of the system. Creation of an account is very simple. From the Welcome screen, click the Open a New SPS Bugzilla Account. The page displayed in Figure 3.1 Create a new SPS Bugzilla account is what the user will use to create the account. The user will enter their address and name in the correct fields. Once the [Create Account] button is clicked, SPS-B will send the user their password. The time necessary to receive your password will vary depending on SPS-B load, network conditions, and systems. If you have not received a password within an a hour, please contact the GTF. Once an account has been established, the user is ready to log in and use the system. If a tester is not at their local site and does not have access to their regular account via the Internet, Appendix B provides information on creating a free web-based account with Yahoo! Web mail. However, we do prefer users to use their official government address if possible. Figure 3.1 Create a new SPS Bugzilla account 4

7 If the account creation is successful, the user will see a screen similar to the one in Figure 3.2 Successful Account Creation. The tester100@test.mil will be replaced with user s address. If unsuccessful, the user will receive an error message to inform them of the problem. Figure 3.2 Successful Account Creation 5

8 4.0 Log In and Log Out Anyone who wants to access any testing data must log in to the system. Section 3.0 provides information on creating an account. Once the user receives their password they are able to log into the system. To access the system, from the welcome page, the user must click the Log in to an existing account link. The log in page, shown in Figure 4.1, will be displayed. The user enters their username ( address) and password and clicks the [Log In] button. The password is case-sensitive. If the log in was successful, the tester will be taken to the query page automatically. The query page is the default since the first step to writing up an issue is to see if the error has been previously reported. Figure 4.1 Log In New in SPS-B in this version is an automatic log out. If there is no activity in the system for 45 or more minutes, the user will be logged out. The screens may appear the same to the user until they try to add or update an issue. An easy way to tell if the user has been logged out is to refresh the current page and look at the navigation bar at the bottom of the screen. If the user has been logged out it will say Log In rather than Log Out <user s address>. When the tester wants to leave the system, they just need to click the Log Off option in the Navigation bar and the log off screen will be displayed as shown in Figure 4.2 Log Out. 6

9 Figure 4.2 Log Out 7

10 5.0 Querying the Database SPS-B has a very robust querying/search function. The query page, which is shown in Figure 5.1, allows the user to use a variety of options (e.g. words/strings) to find issues that meet their criteria. These search options can be used individually or combined. Users can search for items included in the issue summary, problem URL, or additional comments. The user can search based on DAG resolution or Service Activity. Fields like DAG resolution and impact can have multiple options selected or none at all. If a tester selects an option in this type of field and decides that they want to unselect the item, all they have to do is hold down the control (Ctrl) key and left mouse click on the option to be removed. The search page is cumulative. The more options added or left the more refined your results will be. The default query, what is selected when the user logs in, has been changed. A new field DAG Ready has been added with a pre-selected option. This default query will be the query used for Data Authentication Group (DAG) meetings except the user must select the software component and version prior to clicking the [Search] button. Prior to clicking the search button, the user has several options. Under the and Numbering section, there are three radio buttons. The first (the default) states Run this query. The second Remember this as my default query, allows the tester to have this query appear every time they display the query page. The third option Remember this query, name it, allows the user to save the query with a name so that they can use it over again without making it their default query. The check box labeled and put in my footer provides the tester the option of placing the query name on the user s Navigation Bar for easy access. The named queries will appear to the right of the My Issues query. The My Issues query displays a list of all issues written by that tester. The tester can also determine the sort order by making a selection from the Sort results by drop down list. 8

11 Figure 5.1 Query Page Once the tester is satisfied with their query, they click the search button and the results window, shown in Figure 5.2, will be displayed. The results window displays the issues requested in the query. The information provided is issue number, impact, tester, service activity, DAG Resolution, and issue summary. The tester can re-sort the results by clicking on the column header of the column that they would rather have the results sorted by. 9

12 Figure 5.2 Results Window 10

13 If the listed results do not provide enough information to the user, the user can click the [Long Format] button to display the results with more information. An example of the long format can be seen in Figure 5.3. Figure 5.3 Long Format The long format provides all of the current information on an issue. However, the information is read-only and the user cannot add attachments or additional comments. To add comments or attachments the user can click the issue number and be taken to the edit page. 5.1 Export data to CSV A new feature added to the long format of issues is the ability to export the information for use in Microsoft Excel. At the bottom of page before the navigation bar, there is a button label [Export to CSV]. Next, the user will be prompted for a save location for the file. Figure shows the prompt to save. 11

14 Figure Save Prompt The user clicks [OK] and chooses a name and location for the file. When naming the file change the file extension to.csv. This will allow Microsoft Excel to correctly identify the file type. Figure shows an example. After entering a filename and choosing a location, the user clicks [Save]. Figure Example of filename selection To open the newly created file, the user must open Microsoft Excel. The following screen shots are from Microsoft Excel The users screen may look different. From the menu bar select Data, Get External Data, and Import Text File as shown in Figure

15 Figure Microsoft Excel Selections The user then locates the file saved above using window shown in Figure Figure Locate File After the desired file is located and selected, click [Import]. This is will prompt the Text Import Wizard window to open as shown in Figure

16 Figure Text Import Wizard On the first screen of the wizard, click [Next]. On the next screen, shown in Figure 5.1.6, uncheck the box labeled Tab. Select the checkbox for Other and enter a tilde (~) in the box to the right of the word Other. Click [Finish] once the values are correct. Figure Select Correct Delimiter Another dialog box will open, as shown in Figure 5.1.7, that will ask where should the imported data be opened into. Keep the default location and click [OK]. The data will display similar to 14

17 Figure After that the user can manipulate the data just like any other Microsoft spreadsheet. The tester should have the new spreadsheet with a name and an.xls extension. Figure Location Dialog Figure Created Spreadsheet 15

18 6.0 Create New Issue Allowing users to create new issues is the primary purpose for SPS-B. To create a new issue, the user needs to click on the New link in the Navigation Bar at the bottom of the page. This will open the Enter Issue screen. Figure 6.1 shows the Enter Issue screen. To help the user, at the bottom of each page there is a Navigation Bar. This bar provides quick access to each of the SPS-B sections and the user s preferences. 16

19 Figure 6.1 Enter Issue Page At the top of the screen there are two recommendations. The first recommendation is for the tester to review the issue writing guidelines, which can be found in Appendix A of this document 17

20 or online if link is clicked, before writing any issues. The issue writing guidelines provide information on the correct way to write up an issue. This is important for all testers to read regardless of their previous testing experience. The second recommendation is to search the database for similar issues before writing an issue up. This is to help prevent duplicate issues from being written. A tester may decide to add a comment to a previous issue to provide additional information about the problem. The only exception to this is when the previous issue has been scored. If it has been scored, the tester writes up a new issue and references the previous issue number. A new field has been added for the testers. The field is requirement number. The testers are now responsible for adding the requirement number that fails to their issue. If no specific requirement can be assigned to the issue the tester will enter NA or Not applicable. This field is a required field. The user will receive a red error message if they fail to enter a requirement number. There are 14 fields that can be entered on the Enter issue page. With the exception of EDI Transactions, Legacy Integrations, Script Name, Document Number and Problem URL, all other fields must be filled in for the issue to be saved. If the field name is in blue, the name can be clicked on to provide a definition of what needs to be entered in the field. The field name and definitions are provided in Table 6.1 Enter Issue Fields. 18

21 Table 6.1 Enter Issue Fields Number Field Name Field Contents 1 Software Components Software being tested (e.g. PD2, Adapter, etc.) 2 Version Version number of the software being tested (e.g , Inc 2 SR02, etc.) 3 EDI Transactions What file type is being tested (840, 850, 860, etc.) OB Outbound, IB Inbound 4 Legacy Integrations Which translator is being tested 5 Platform Type of machine software is being tested on. 6 OS Operating system of machine software is being tested on 7 Service Activity Group that the tester is representing (e.g. Army, Navy, GTF, etc.) 8 Impact The testers opinion on how the problem affects the overall product performance. 9 Issue Summary Brief, concise description of issue 10 Source Document Enter the Operational Scenario/Script Name 11 Document Number The unique identifier of the form/document the tester was using when error occurred 12 Requirement Number The requirement number that fails. This can be a JRB requirement, business rule, or v4.2 failed requirement. Enter NA if not applicable 13 Problem URL: Address of the software at the time it broke. This applies to PD2 v4.2 Increment 3 14 Description Full and detailed description of the issue After clicking [Save], the system will inform the tester whether the submission was successful and if so, their issue number. The issue numbers are assigned in numeric order regardless of the software component. The tester could enter one issue against PD2 and then one against Adapter and have sequential issue numbers. Figure 6.2 Successful Submission shows the successful submission screen. As part of the submission screen, the screen displays the issue, as it will appear to everyone. If the tester tries to go back to the issue, they will find out that they will not be able to edit it. Once [Save] is selected, the issue is put into the database and the description is unchangeable. The tester can only add attachments and comments after the issue is saved. Adding attachments will be discussed under Edit/Update Issues. 19

22 Figure 6.2 Successful Submission 20

23 7.0 Edit/Update Issues The editing/updating of the issues is extremely limited. By design, the only thing that a user can add to an issue is an attachment or an additional comment. The information that a user enters initially is locked from all editing. If a tester wants to add a screen shot or other file to an issue, that is possible from the edit page only. If the tester makes a mistake or finds more information about the problem, they can indicate this through the Additional Comments field on the edit page. It is also possible for a tester to add/change/remove an entry from the requirement number field. Figure 7.1 shows the edit screen page. Test site managers (TSM) have new responsibilities with version 1.2. These new responsibilities will be covered in section

24 Figure 7.1 Edit Page

25 The edit screen consists of four sections, the general information, the additional information, the description/comments, and other features. The general information consists of 24 data elements, which include the issue number, tester name and other related information. Table 7.1 shows a list of the general information. The number indicates the corresponding number on Figure 7.1, which shows where on the screen a specific data element appears. Additional information is the main area that is editable for the tester. This section is where the tester can add attachments (25), add additional comments (26), or add reference numbers (27) on Figure 7.1. Description/comments section (30) is the area where the tester or reviewer can read the issue description or the comments made by other users in the system. Each comment contains the name of commenter and the date/time stamp of when the comment was made. Other features are the standard options that testers have on the edit page. Some are system functions, items 28 and 29. Most of the additional features are navigational, for example moving to the first issue on the testers query results page or returning to the query results page. The tester can find these options marked 31 and 32 on Figure

26 Table 7.1: General Information Number Date Element Description 1 Issue # Issue Number 2 Platform Type of Machine issue was discovered on 3 Tester Person who submitted the issue 4 Product Product issue is being written against 5 Software Component The component software the issue is being written against 6 Version Version of the software the issue is being written against 7 DAG Resolution The DAG s decision on what will happen to the issue 8 EDI Transaction Which transaction is being tested? 840, 850, and Legacy Interface Which Translator is being tested? 10 Service Activity Organization of the tester who submitted the issue 11 Impact User s opinion of the effect the issue will have on the software 12 OS Operating system issue was discovered on 13 JPMO Category JPMO Representative suggested resolution based on requirement 14 CM Number Unique tracking number used by Configuration Management 15 Vendor Number The software vendor s internal tracking system number assigned to the issue 16 Issue Summary Short description of issue. Maximum of 60 characters 17 Requirement Number Field to store the requirement number related to the issue 18 Source Document Title of test document be used 19 Document Number The form/document being used when error occurred 20 Problem URL The URL where the issue was discovered 21 DAG Ready? Flag to be set by TSM when issue is ready to be discussed at the DAG meeting 22 Issue to be Fixed The issue has been placed on contract to be fixed 23 Version Fix Due The version of software when fix is due to be incorporated 24 Issue Fixed The fix has been tested and is fixed 7.1 Create Attachments The edit page is where testers will add attachments. Attachments can be screen shots, Microsoft Word document, or any other file type. When an attachment is created the tester will be asked for three things, the file name and location, type of file and comments about the attachment. To create an attachment for an issue, locate the issue using the query page or use the Find Issue box available in the navigation bar. When the edit page opens, scroll (if necessary) to the Attachment box found before the Additional Comments box, number 25 on Figure 7.1. Click the Create a New Attachment link. The Create New Attachment page, shown in Figure 7.2, will open. 24

27 Figure 7.2 Create a New Attachment The tester will then complete the form and click [Submit]. The tester will use the [Browse] button to find and select the file they wish to attach to the problem. In the Description box, the tester will provide a brief description of the attachment. For example, attachment is a screen shot of the received error message. For content type, the tester will select auto-detect. This allows SPS-B to determine the type of file the tester is trying to attach. In cases where SPS-B cannot determine the file type, the tester can either pick from the drop down provided or enter a new file type in the enter manually box. Obsoletes will only appear if there are more than one attachment on a given issue. Obsoletes was originally designed for cases where a software patch is added to an issue as part of issue closure. We are not using this functionality in that manner. We will use this field when a new attachment should replace the previous attachment since attachments cannot be deleted. This is an optional field. In the majority of cases, the tester will not use this field. The Comments field can be considered like the additional comments block on the Edit page. This is where the tester would enter why the attachment is important to the issue. 25

28 8.0 Test Site Managers (TSM) Test Site Managers (TSM) has an important additional responsibility with SPS-B version 1.2. The TSMs are responsible for verifying that all necessary information is included in the issue and marking the issue DAG Ready prior to the issue being considered by the DAG. When testers create an issue, the DAG Ready flag is automatically set to No. If this value is not changed by the TSM for the tester s site, this issue will not be discussed in DAG. By marking as DAG Ready, the TSM agrees that the information is complete and has been retested by at least one tester at the site. The values available for a DAG Ready is Yes or No. A DAG Ready of No is effectively a closed issue. TSMs will receive an notification of each new issue written by one of their testers as well as notifications of any changes made to one of their testers issues. TSM s have a unique edit page where it will allow them to add attachments, add/change requirement number, mark as DAG Ready, and add comments. The only difference between a tester edit screen and a TSM edit screen is that the TSM screen has DAG Ready as an editable field. 26

29 9.0 Reports Reporting is a crucial part of the SPS-B system. The reports are read-only. When the Reports option in the Navigation Bar is clicked the Reports window will open. The reports screen is shown in Figure 9.1. There are three types of reports provided in the system, Scoring Conference Results and two Summaries. These reports are real-time. If a report is being viewed, a press of the reload/refresh button on the browser will update the displayed information. Anyone is able to look at the reports. Figure 9.1 Reports The Scoring Conference Results is a report that displays the scores for each issue by scoring conference member. This report allows users to see the scoring results as it happens. There will be no formal scoring conferences like there has been in the past. Scorers can score as soon as a category that is destined to be scored is placed on an issue. Scoring will be discussed in section 27

30 10 of this document. The users would simply log into the system, click the Reports link in the navigation bar. Then they would select the software component and version that they would like to review. They have the option to look at ALL, FAILED_REQUIREMENT, PRODUCT_DEFECT, TRAINING, or DOCUMENTATION types of issues. An example of a Scoring Conference Results can be seen in Figure 9.2. The report only displays 50 issues at a time. This report can be exported to Excel. There will be Forward and Back links available at the bottom of the page when there are more than 50 issues to be scored. The [Export To CSV] function will only export the issues on the current page. However, you can import them all into the same Excel spreadsheet using the instructions in section 5.1 of this document. The instructions for this functionality can be found in section 5.1 of this document. Figure 9.2 Scoring Conference Results The summary reports are provided through the SPS Bugzilla Query Kitchen. There are two types of summary reports. The first type is Issue Counts. Issue counts provide information on the number of issues in various categories. Figure 9.3 Issue Counts show the various information types available with an issue count summary. These reports can and should be restricted to the software component and version that the user wishes to see. Otherwise, the user will see the issue counts of all of the issues in the database, regardless of when it was entered or against what software component. 28

31 Figure 9.3 Issue Counts 29

32 The second type of summary report is the Issues Scored reports. These reports show the results of the Scoring Conference members. This report will be updated as final scores are placed against the issues. Figure 9.4 Issues Scored shows what these reports will look like. These reports show the total number of issues that have been scored based on priority number, displays the scored issues by service activity, and provides links to the various issues. Service Activity is the activity placed against the issue from the New Issue page. Figure 9.4 Issues Scored After an issue is scored, no further comments or attachments can be added to the issue. Figure 9.5 shows what the edit page looks like after an issue has been scored. 30

33 9.5 Edit page of Scored Issue 31

34 10.0 Scoring The entire scoring module was redesigned for SPS-B v1.2. This new functionality will allow all of the scorers to score issues online. There are now seven scorers. Each scorer represents a different group of SPS users. There are scorers from the Army, Navy, Air Force, ODA and also include the Technical and Functional Division Chiefs as well as the Program Manager (PM). They will have real-time access to all of the information needed to make scoring decisions. Scorers get notifications when there are issues that they need to address. The first , and possibly only , will notify the scorer that there is an issue to be scored. The will include the issue number and the category that it was assigned to. A second will be sent if there is no four score majority opinion on an issue after all six scorers have scored or there is a majority score of one (1) but it is not unanimous. This second will include the issue number and a statement about a teleconference being necessary. The PM or his alternate can log in and issue a final score at any time. Scorers will no longer score from a report screen. The scorers have their own edit screens. Their screens are different from the tester and TSM screens. They only see pertinent issue data and can only add attachments, comments, and their score. They do not have access to the other scorers scores from their edit screen. The scorer s screen is displayed in Figure

35 Figure 10.1 Scorer s Edit Screen (Technical Division Chief s Screen) There are three ways a scorer can get to their edit screens. The first is to use the search feature to select the software component(s), version, and resolutions for scoring of the issues they want to 33

36 see. The second is to use the Find function in the navigation bar to go directly to an issue using the issue number included in the notification . Lastly, they can view the Scoring Conference Results report and click on the issue number of the issue they would like to score. 34

37 11.0 User Preferences There are several user preferences that can be modified to meet the user s needs. User preferences can only be accessed after the user logs into the system. After logging in, the user will notice a prefs link on the right side of the Navigation Bar. The first tab is Account Settings, shown in Figure On this tab, the user can change their password and/or address and verify their name. The first, and maybe the most important, is the ability to change passwords. This should be done soon after the user receives their password from SPS-B. To change any setting, the user will be asked to supply their current password. The next tab is settings, shown in Figure The settings control how much a tester receives from SPS-B. The system defines several types of users. However, SPS-B only utilizes Tester and Assignee. By default, the system sends an to the tester and assignee every time there is a change made to the tester s issue. The assignee is the GTF Staff Member assigned to monitor the issues written against a specific software component. It is recommended that a tester uncheck all checkboxes in the Assignee, CC, and Voter columns. The Page Footer tab, shown in Figure 11.3, determines whether or not a tester has the My Issues link in their Navigation Bar, sometimes referred to as the footer. It is recommended that this not be changed. The final tab is the Permissions tab, shown in Figure All this tab does is inform the user of what they are allowed to do in the system. Figure 11.1 User Preferences Account Settings Tab 35

38 Figure 11.2 User Preferences Settings Tab Figure 11.3 User Preferences Page Footer 36

39 Figure 11.4 User Preferences Permissions 37

40 APPENDIX A SPS Bugzilla Issue Writing Guidelines

41 APPENDIX A Why You Should Read This Simply put, the more effectively you report an issue, the more likely the SPS JPMO will have it fixed. These guidelines are a general tutorial to teach novice and intermediate software testers how to compose more effective issue reports. Not every sentence may precisely apply to your situation. How to Write a Useful Issue Report Useful issue reports are ones that get issues fixed. A useful issue report normally has two qualities: 1. Reproducible. If another tester or developer can't see the issue themselves to prove that it exists, they will probably stamp your issue report "CLOSED" and move on to the next issue. Every detail you can provide helps. 2. Specific. The quicker another tester or developer can isolate the issue to a specific area, the more likely they will expediently fix it. (If another tester or developer has to decipher an issue, they may spend more time cursing the submitter than solving the problem.) Let's say the application you're testing is a web browser. You crash at foo.com, and want to write up an issue report: BAD: "My browser crashed. I think I was on I play golf with Bill Gates, so you better fix this problem, or I'll report you to him. By the way, your Back icon looks like a squashed rodent. UGGGLY. And my grandmother's home page is all messed up in your browser. Thx 4 UR help." GOOD: "I crashed each time I went to using the build on a Windows 2000 system. I also rebooted into Linux, and reproduced this problem using the Linux build. It again crashed each time upon drawing the Foo banner at the top of the page. I broke apart the page, and discovered that the following image link will crash the application reproducibly, unless you remove the "border=0" attribute: <IMG SRC=" width="34" height="44" border="0" alt="news"> How to Enter your Useful Issue Report into SPS Bugzilla: Before you enter your issue, use SPS Bugzilla's search page to determine whether the defect you've discovered is a known, already-reported issue. If your issue is the 37th duplicate of a known issue that you replicated, just report it again without wasting much time being creative and detailed. If possible, enter the number of the issue duplicated in the problem description. 1. From your SPS Bugzilla main page, choose "Enter a new issue". 2. Select the product that you've found a bug in. 1

42 APPENDIX A 3. Enter your address, password, and press the "Login" button. (If you don't yet have a password, leave the password field empty, and press the " me a password" button instead. You'll quickly receive an message with your password.) Now, fill out the form. Here's what it all means: Where did you find the issue? Product: In which product did you find the issue? You just specified this on the last page, so you can't edit it here. Version: In which product version did you find the issue? Software Component: In which software component does the issue exist? SPS Bugzilla requires that you select a software component to enter an issue. (Not sure which to choose? Click on the Software Component link. You'll see a description of each software component, to help you make the best choice.) OS: On which Operating System (OS) did you find this issue? (e.g. Windows 2000, Windows XP, Linux.) If you know the issue happens on all OSs, choose 'All'. Otherwise, select the OS that you found the issue on, or "Other" if your OS isn't listed. How important is the issue? Impact: How damaging is the issue? This item defaults to 'minor'. If you're not sure what impact your issue deserves, click on the Impact link. You'll see a description of each impact rating. Who will be following up on the issue? Cc: Who else should receive updates on changes to this issue? List the full addresses of other individuals who should receive an update upon every change to the issue report. Every change means that every time any change is made to the issue, an is sent. This includes but is not limited to new comments, changes in DAG resolution or DAG status, or change in scoring conference decisions. You can enter as many addresses as you'd like, separated by spaces or commas, as long as those people have SPS Bugzilla accounts. What else can you tell another tester or developer about the issue? Issue Summary: How would you describe the issue, in approximately 60 or fewer characters? A good issue summary should quickly and uniquely identify an issue report. Otherwise, another tester or developer cannot meaningfully identify your issue by 2

43 APPENDIX A its issue summary, and will often fail to pay attention to your issue report when skimming through a 10-page issue list. A useful issue summary might be "PCMCIA install fails on Tosh Tecra 780DVD w/ 3c589C". "Software fails" or "install problem" would be examples of a bad issue summary. Description: Please provide a detailed problem report in this field. Your issue's recipients will most likely expect the following information: Overview Description: More detailed expansion of issue summary. Drag-selecting any page crashes Windows 2000 using Internet Explorer 5.5 Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the issue. Include any special setup steps. 1) View any web page. 2) Drag-select the page. (Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser's content region to the bottom of the browser's content region.) Actual Results: What the application did after performing the above steps. The application crashed. Dr. Watson error appended below. Expected Results: What the application should have done, were the issue not present. The window should scroll downwards. Scrolled content should be selected. (Or, at least, the application should not crash.) Build Date & Platform: Date and platform of the build that you first encountered the issue in. Windows 2000 Service Pack 3 Additional Builds and Platforms: Whether or not the issue takes place on other platforms (or browsers, if applicable). 3

44 APPENDIX A You're done! - Also Occurs On Internet Explorer 5.0 (shipping build on Windows NT 4.0) - Doesn't Occur On Internet Explorer 6.0 (shipping build on Windows XP) Netscape Communicator 4.7 (shipping build on Windows NT 4.0) Mozilla ( build on Red Hat Linux; feature not supported) Additional Information: Any other debugging information. For crashing issues: Win32: if you receive a Dr. Watson error, please note the type of the crash, and the module that the application crashed in. (e.g. access violation in apprunner.exe) Mac OS: if you're running MacsBug, please provide the results of a how and an sc: After double-checking your entries for any possible errors, press the "Save" button, and your issue report will now be in the SPS Bugzilla database. 1. General Tips for a Useful Issue Report More Information on Writing Good Issues Use an explicit structure, so your issue reports are easy to skim. Issue report users often need immediate access to specific sections of your issue. If your SPS Bugzilla installation supports the SPS Bugzilla Helper, use it. Avoid cuteness if it costs clarity. Nobody will be laughing at your funny issue title at 3:00 AM when they can't remember how to find your issue. One issue per report. Completely different people typically fix, verify, and prioritize different issues. If you mix a handful of issues into a single report, the right people probably won't discover your issues in a timely fashion, or at all. Certain issues are also more important than others. It's impossible to prioritize an issue report when it contains four different issues, all of differing importance to various people. No issue is too trivial to report. Unless you're reading the source code, you can't see actual software issues, like a dangling pointer -- you'll see their visible manifestations, such as the segfault when the application finally crashes. Severe software problems can manifest themselves in superficially trivial ways. File them anyway. 4

45 APPENDIX A 2. How and Why to Write Good Issue Summaries You want to make a good first impression on the issue recipient. Just like a New York Times headline guides readers towards a relevant article from dozens of choices, will your issue summary suggest that your issue report is worth reading from dozens or hundreds of choices? Conversely, a vague issue summary like install problem forces anyone reviewing installation issues to waste time opening up your issue to determine whether it matters. Your issue will often be searched by its issue summary. Just as you'd find web pages with Google by searching by keywords through intuition, so will other people locate your issues. Descriptive issue summaries are naturally keyword-rich, and easier to find. For example, you'll find an issue titled "Dragging icons from List View to gnometerminal doesn't paste path" if you search on "List", "terminal", or "path". Those search keywords wouldn't have found an issue titled "Dragging icons doesn't paste". Ask yourself, "Would someone understand my issue from just this issue summary?" If so, you've written a fine issue summary. Don't write titles like these: 1. "Can't install" - Why can't you install? What happens when you try to install? 2. "Severe Performance Problems" -...and they occur when you do what? 3. "back button does not work" - Ever? At all? Good Issue titles: 1. "1.0 upgrade installation fails if Netscape 4.74 package present" - Explains problem and the context. 2. "The installer crashes if launched on a Windows XP system" - Explains what happens, and the context. (SPS Bugzilla Issue Writing Guidelines modified and maintained by Wendy Bozenhard. Constructive suggestions welcome.) Original Bugzilla Bug Writing Guidelines document was written by Eli Goldberg, Claudius Gayle, Gervase Markham, Peter Mock, Chris Pratt, Tom Schutter and Chris Yeh also contributed significant changes. 5

46 APPENDIX B Create web-based Account

47 APPENDIX B This appendix will provide information on how to create a web-based account using the web mail service provided by Yahoo!. 1. Open any web browser, like Internet Explorer, Netscape, Mozilla, etc. 2. In the Address bar, type in 3. When the Yahoo! Page opens; click the Mail icon at the top, directly to the right of the Yahoo name. 1

48 APPENDIX B 4. The Yahoo! Mail Welcome Screen will be displayed. From that screen the tester will click Sign Up Now 5. When provided with levels of service, the tester will click Sign Up Now, in the box labeled Free Yahoo! Mail. 2

49 APPENDIX B 6. Fill out the form presented and click the [Submit this Form] button at the bottom of the page. The amount of data entered in this form is at the discretion of the tester. Please read all information provided prior to clicking the [Submit this Form] button. It is possible that the ID that the tester enters into the Yahoo! ID block may already be taken. In that case, the system will prompt the tester to try again. Once the Yahoo! ID is accepted the tester s address will be their Yahoo! ID@yahoo.com. Yahoo! has two rules with the free account. First, the account must be logged into at least once every 30 days or 3

50 APPENDIX B it will be deactivated. Second, the account cannot hold more than 4 MB of data. There is one additional benefit of creating a Yahoo! account. The ID that is created can be used with the Yahoo! Instant Messenger. However, logging into Instant Messenger does not count against the once every 30-day restriction. 4