DRAFT. Wide Area Workflow (WAWF) Trouble Ticket Tracker (T3) Training Manual

Transcription

1 Wide Area Workflow (WAWF) Trouble Ticket Tracker (T3) Training Manual Version 1.0 October 2012

2 TABLE OF CONTENTS: 1.0 Overview Opening T Create a New Account Log In and Log Out of System T3 Navigation Bar Querying the Database Export Data to Comma Separated Value (CSV) Format Create New Ticket Edit/Update Ticket Create Attachments Developer Representative Reports 23 LIST OF FIGURES: 2.1 T3 Welcome Page Create New Account Successful Account Creation Log In Log Out T3 Navigation Bar Query Page Results Window Results Window Long Format Enter Issue Page Successful Submission Edit Page Create New Attachment Successful Attachment Developer Representative Edit Screen Reports Issue Counts Issues Scored Edit Page of Scored Issue 27 B.1 Save Prompt B-1 B.2 Example of Filename Selection B-2 B.3 Microsoft Excel Selections B-2 B.4 Locate File B-3 B.5 Text Import Wizard B-3 B.6 Select Correct Delimiter B-4 B.7 Location Dialog B-4 B.8 Created Spreadsheet B-5 C.1 User Preferences Account Settings C-1 C.2 User Preferences Settings C-2 i

3 C.3 User Preferences Page Footer C-3 C.4 User Preferences Permissions C-4 LIST OF TABLES: T3 Navigation Bar Features Enter Issue Fields General Information 18 APPENDICES: A. T3 Issue Writing Guidelines B. Export Data to Comma Separated Value (CSV) Format C. User Preferences ii

4 1.0 Overview The Wide Area Workflow (WAWF) Program Management Office (PMO) is providing a web based trouble ticket tracking system called WAWF Trouble Ticket Tracker (T3) to support production issues With WAWF. This software will provide additional capabilities and greater issue visibility and processing transparency to all users of WAWF. This documentation provides a detailed instructional guide on how to use this software. It provides descriptions, screen shots, and detailed instructions. This information is intended for every user of the software. 1

5 2.0 Open Trouble Ticket Tracker (T3) To access Trouble Ticket Tracker (T3), open an internet web browser. T3 is compatible with a variety of web browsers including, but not limited to Internet Explorer, Chrome, and Safari. The universal resource locator (URL) is This link will open the T3 home page see Figure 2.1. Figure 2.1 T3 Welcome Page 2

6 3.0 Create New Account A user account must be created to be able to access any data in T3. User permissions to the system will be associated with their account name. Creation of an account is very simple. From the Welcome screen, click the Open a New T3 Account. The page displayed in Figure 3.1 Create a new T3 account is what the user will use to create the account. The user will enter their address and name in the appropriate fields. Once the [Create Account] button is clicked, T3 will send the user their password. The time necessary to receive your password will vary depending on T3 load, network conditions, and systems. If you have not received a password within an hour of account creation, please contact the T3 administrator. Once an account has been established, the user is able to log in and use the system. All new user accounts will, by default, have read-only access. 3

7 Figure 3.1 Create a new T3 account 4

8 If the account creation is successful, the user will see a screen similar to the one in Figure 3.2 Successful Account Creation. The [email protected] will be replaced with user s address. If unsuccessful, the user will receive an error message to inform them of the problem. User accounts can be disabled by system administrator. Users whose accounts have been disabled will be presented with a red error message. Users will have to contact the T3 administrator to get the account activated and/or reactivated. Information on how to disable an account will be covered in the system administrator s guide. The system administrator s guide is still in development. Figure 3.2 Successful Account Creation 5

9 4.0 Log In and Log Out Anyone who wants to access any 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 and password and clicks the [Log In] button. The username is the address that was used to create the account. 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 a ticket is to see if the error has been previously reported. Figure 4.1 Log In The T3 application has an automatic log out feature. If there is no activity in the system for 30 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. The easiest 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>. 6

10 When the tester wants to leave the system, they 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. It is highly recommended that users do not use the X to close the browser while the software is still logged in. It can create connection issues with the server. Figure 4.2 Log Out 7

11 4.1 T3 Navigation Bar At the bottom of every page of T3, there is a yellow box called the T3 Navigation Bar shown in Figure The Navigation Bar contains useful links to allow the users to navigate through the software. Table lists each of the options in the Navigation Bar with a description of what it does. If a user opens a page accidentally or needs to cancel an action, they can use either the links in the Navigation Bar or the Back button on their browser to leave the page. Please note: if a user only has a read-only account, the New option will not appear in their Navigation Bar. Figure T3 Navigation Bar Table Navigation Bar Features Options Description Discussed further in New Will take the users to the new issue page Section 6 Query Will take the users to the query screen Section 5 Ticket #/Find This allows users to go straight to the edit screen of a specific ticket. Enter ticket number in block and click [Find]. Reports Will take users to the reports screen Section 9 Help Will open the online help Prefs Will open the user preferences screen Appendix D Log out Will log the user out of the software Section 4 My Issues Will show the users all of the issues in the system that they have written 8

12 5.0 Querying the Database T3 has a very robust query/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 tickets that meet their criteria. These search options can be used individually or combined. Users can search for items included in the title, browser version, or additional comments among others. Some fields like status and Doc Type can have multiple options selected or none at all. If a tester selects multiple options or a single 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. In list box fields, users can type in the first letter of the desired option to be jumped nearer to required option to reduce the amount of scrolling required. The search page is cumulative. With every additional criterion selected the more refined the search it will be. If you are having trouble finding tickets that you know exist, reduce the number of options selected on the query screen. Users have two types of help on the Query Screen. At the bottom of the page, there is a statement Give me a clue about how to use this form. If the user clicks the word clue, they will be taken to a detailed explanation of the query page and what each of the fields represents. The other type of help is the field names that are hyperlinks, indicated by blue text. If a user clicks on the field name, they will be taken to a description of that specific field. Saving Query Options: Users have the ability to save queries that they use multiple times to save time rather than recreate them each time they require the data. Prior to clicking the search button, the user has several save query options. Under the and Numbering section, there are three radio buttons. The first (the default) states Run this query. This just runs the query as configured. 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 reuse it 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 tickets written by that user. The user can also determine the sort order by making a selection from the Sort results by drop down list. Users can also remove saved queries when they are no longer necessary. To remove a named query, in the save query option section, select the named query, select the Forget my remembered query, and click the [Search] button. The named query will be removed. 9

13 Figure 5.1 Query Page Save Query Clue 10

14 Once the user is satisfied with their query, they click the search button and the results window, similar to the one shown in Figure 5.2, will be displayed. The issue list contains the results of the user s query. The information provided is ticket number, user , submitter organization, resolution, and title. The user can re-sort the results by clicking on the header of the desired sort column. By default, the initial search results are sequentially sorted by issue number. Figure 5.2 Results Window Long Format Button 11

15 If the listed results do not provide enough information to the user, the user can click the [Long Format] button, located at the bottom left of the results, 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 from this view. To add comments or attachments the user can click the ticket number and be taken to the edit page. 5.1 Export data to Comma Separated Value (CSV) Format T3 includes a feature to export the information included in the long format of tickets for use in Microsoft Excel or any other spreadsheet application that uses the comma separated value (CSV) format. For detailed steps on how to export data into this format, please see Appendix B of this document. The screen shots were captured while using Internet Explorer 8.0 and Microsoft Excel The prompts and screens may look different if using a different web browser or spreadsheet application. 12

16 6.0 Create New Ticket Allowing users to create new tickets is the primary purpose for T3. To create a new ticket, the user needs to click on the New link in the Navigation Bar at the bottom of the page. This will open the Enter Ticket screen as shown in Figure 6.1. Figure 6.1 Enter Ticket Page At the top of the screen there are two recommendations. The first recommendation is for the user to review the ticket writing guidelines, which can be found in Appendix A of this document or online via the link, before writing any tickets. The ticket writing guidelines provide information on the correct and most effective way to write up a ticket. This is important for all users to read regardless of their previous experience. The second recommendation is to search 13

17 the database for similar tickets before writing a new ticket. This reminder is to help prevent duplicate tickets from being written. The ticket process is that if a similar ticket exists and if it is open for comments the user should comment the existing ticket. If the similar ticket exists and is closed for comment, a new ticket is created with a reference back to the previous ticket. In the first case, it will provide additional information for those conducting research that the ticket is replicable and there may be new information on how to replicate it. The second case shows traceability of a ticket over time. There are cases when tickets are found, fixed, and then broken again in a subsequent release. The majority of the 15 fields on the new ticket page are required for the ticket to be saved. The exceptions are: Applicable External System, Role, Payment System, and DR Number. Failure to enter a required field will result in an error message. 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. Table 6.1 Enter Issue Fields Number Field Name Field Contents 1 Application The area of package where issue was found 2 Version Version number of the application being reported 3 Applicable External System <Definition to be provided> 4 Payment System <Definition to be provided> 5 Doc Type <Definition to be provided> 6 Role <Definition to be provided> 7 Submitter Organization Agency that the user is reporting from 8 Title Brief, concise description of issue 9 Ticket Number <Definition to be provided> 10 DR Number <Definition to be provided> 11 Browser Version The name and version of the web browsing software being used 12 Submitter Name User s name 13 Submitter Phone User s phone number 14 Submitter User s address 15 Description Full and detailed description of the issue After clicking [Save], the system will inform the user whether the submission was successful and if so, their ticket number. The ticket numbers are assigned in numeric order regardless of the application selected. The user could enter one ticket against EDA and then one against EDI and have sequential ticket numbers. Figure 6.2 Successful Submission shows the successful submission screen. As part of the submission screen, the screen displays the new ticket, as it will appear to everyone. If the user tries to go back to the ticket, they will find out that they will not be able to edit it. Once [Save] is selected, the ticket is put into the database and the description is unchangeable. The user can only add attachments and comments after the ticket is saved. Adding attachments will be discussed under Edit/Update Tickets. 14

18 Figure 6.2 Successful Submission 15

19 7.0 Edit/Update Ticket The editing/updating of the tickets is extremely expansive. The only field that cannot be updated is the ticket description. If a user wants to add a screen shot or other file to a ticket, that is possible from the edit page only. If the user makes a mistake or finds more information about the problem, they can indicate this through the Additional Comments field on the edit page. The software is designed to safeguard the information entered by the user. The users should have confidence that what they enter in the new ticket form will be carried forward throughout the ticket process. Figure 7.1 shows the edit screen page. WAWF Developers only have the ability to add comments and/or attachments 16

20 Figure 7.1 Edit Page

21 The edit screen consists of four sections, the general information, the additional information, the previously entered description/comments, and other features. The general information consists of 21 data elements, which include the ticket number, user 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. Table 7.1: General Information Number Date Element Description 1 Ticket # Ticket Number 2 Reporter Person who submitted the ticket 3 Product Product ticket is being written against 4 Application The package the ticket is being written against 5 Version The version of software being reported against 6 Applicable External System <Definition to be provided> 7 Status The discussion groups decision on the ticket, both temporary and final status 8 Role <Definition to be provided> 9 Payment System <Definition to be provided> 10 Submitter Organization Organization submitter is associated with 11 Doc Type <Definition to be provided> 12 Title Short description of problem. Maximum of 60 characters 13 Ticket Number <Definition to be provided> 14 DR Number <Definition to be provided> 15 Browser Version Name and version of the web application being used when problem discovered 16 Submitter Name Name of person reporting problem 17 Submitter Phone Submitter s telephone number 18 Submitter Submitter s address 19 Ticket to be Fixed The ticket has been placed on contract to be fixed 20 Version Fix Due The version of software when fix is due to be incorporated 21 Ticket Fixed The fix has been tested and is fixed Additional information is where the user can add attachments (22), add additional comments (23), or add reference numbers (24) on Figure 7.1. Description/comments section (25) is the area where the user can read the ticket description and/or the comments made by other users in the system. Each comment contains the name of commenter and the date/time stamp when the comment was made. All comments that are made against a ticket are listed. There is no way to hide a comment once it has been made. This provides for greater data transparency. Other features are the standard options that users have on the edit page. Item 26 is the view issue activity link. This function shows a quick overview of all ticket changes since the ticket was submitted. Item 27 is the format for printing feature. It will convert the screen to make the data a little easier to print. Most of the additional features are navigational, for example moving to 18

22 the first issue on the users query results page or returning to the query results page. The user can find these options marked 28 and 29 on Figure Create Attachments The edit page is where users will add attachments. Attachments can be any file under one megabyte (1MB) in size. These files could be screen shots, Microsoft Word documents, or any other file type. When an attachment is created the user will be asked for a few pieces of information like the file name and location, type of file and comments about the attachment. To create an attachment for a ticket, locate the ticket using the query page or use the Find Ticket box available in the navigation bar. When the edit page opens, scroll (if necessary) to the Attachment box located above the Additional Comments box, number 23 on Figure 7.1. Click the Create a New Attachment link. The Create New Attachment page, shown in Figure 7.2, will open. 19

23 Figure 7.2 Create a New Attachment The user will use the [Browse] button to find and select the file they wish to attach to the problem. Only one file can be attached at a time. In the Description box, the user will provide a brief description of the attachment. For example, attachment is a screen shot of the received error message. For content type, the user will select the auto-detect radio button. This allows T3 to determine the type of file the user is trying to attach. In cases where T3 cannot determine the file type, the user can either pick from the drop down provided or enter a new file type in the enter manually box. The Comments field can be considered like the additional comments block on the Edit page. In this field the user can add specific comments about the attachment or general comments to the ticket. Once the information has been completed the user will click the [Submit] button. A successful attachment screen will look similar to the image in Figure 7.3 Successful Attachment. Please note, the attachment number does not match the ticket number. Attachments are numbered sequentially independently of ticket numbers. 20

24 Figure 7.3 Successful Attachment 21

25 8.0 Developer Representatives Developer representatives have a very restricted access to editing tickets. They are allowed to add additional comments and attachments. Figure 8.1 shows the developer edit screen. Figure 8.1 Developer Representative Edit Screen 22

26 9.0 Reports Reporting is a crucial part of the T3 system. The reports provided by T3 allow anyone with access to the system to keep tabs on what data has been reported to the help desk. For a user to access the reports, they need to click the Reports option in the Navigation Bar. The reports screen is shown in Figure 9.1. There are six types of reports provided in the system. The T3 Report provides information on all tickets associated with application, version, and current status selected by the user. If a user wants to see all tickets, they would select N/A for Application, - for Version, and All for Current Status. The Report Catalog provides reports that show all open tickets, all tickets scheduled for correction, and which tickets have been corrected. All of the 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. All reports are read-only. 23

27 Figure 9.1 Reports The summary reports are provided through the T3 Query Kitchen. There are two types of summary reports. The first type is Ticket Counts. Ticket counts provide information on the number of tickets in various statues. It provides a quick snapshot of how many tickets are associated with the selected option. Figure 9.2 Ticket Counts show the various information types available with a ticket count summary. The user must select an application and version prior to running the report. 24

28 Figure 9.2 Issue Counts The second type of summary report is the Tickets Scored reports. The report will show prioritization by the PM of tickets for correction. This is a legacy report which will never be used. 25

29 Figure 9.3 Issues Scored After a ticket is prioritized, no further comments or attachments can be added to the ticket. Figure 9.4 shows what the edit page looks like after an issue has been closed. 26

30 9.4 Edit page of Scored Issue 27

31 APPENDIX A T3 Ticket Writing Guidelines

32 APPENDIX A Why You Should Read This Simply put, the more effectively you report a ticket, the more likely the WAWF PMO will have it fixed. These guidelines are a general tutorial to teach novice and intermediate software users how to compose more effective ticket reports. Not every sentence may precisely apply to your situation. How to Write a Useful Ticket Report Useful ticket reports are ones that get tickets fixed. A useful ticket report normally has two qualities: 1. Reproducible. If another user or developer can't see the ticket themselves to prove that it exists, they will probably stamp your ticket report "CLOSED" and move on to the next ticket. Every detail you can provide helps. 2. Specific. The quicker another user or developer can isolate the ticket to a specific area, the more likely they will expediently fix it. (If another user or developer has to decypher a ticket, 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 ticket 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 Ticket Report into WAWF Trouble Ticket Tracker: Before you enter your ticket, use T3's search page to determine whether the defect you've discovered is a known, already-reported ticket. If your ticket is the 37th duplicate of a known ticket that you replicated, just report it again without wasting much time being creative and detailed. If possible, enter the number of the ticket duplicated in the problem description. A - 1

33 APPENDIX A 1. From your T3 main page, choose "Enter a new ticket". Now, fill out the form. Here's what it all means: Where did you find the ticket? Product: In which product did you find the ticket? Unless your installation of T3 has more than one product, this will be pre-populated and uneditable. Version: In which product version did you find the ticket? The version allows developers to confirm that you are using the latest package. Application: In which application does the ticket exist? T3 requires that you select an application to enter an ticket. (Not sure which to choose? Click on the Application link. You'll see a description of each application, to help you make the best choice.) What else can you tell another user or developer about the ticket? Title: How would you describe the ticket, in approximately 60 or fewer characters? A good ticket summary should quickly and uniquely identify a ticket report. Otherwise, another user or developer cannot meaningfully identify your ticket by its title, and will often fail to pay attention to your ticket report when skimming through a ten page ticket list. A useful title might be "PCMCIA install fails on Tosh Tecra 780DVD w/ 3c589C". "Software fails" or "install problem" would be examples of a bad title. Description: Please provide a detailed problem report in this field. Your ticket's recipients will most likely expect the following information: Overview Description: More detailed expansion of title. Drag-selecting any page crashes Windows 7 using Internet Explorer 9.0 Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the ticket. 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. A - 2

34 APPENDIX A The application crashed. Dr. Watson error appended below. Expected Results: What the application should have done, were the ticket not present. The window should scroll downwards. Scrolled content should be selected. (Or, at least, the application should not crash.) You're done! After double-checking your entries for any possible errors, press the "Save" button, and your ticket report will now be in the T3 database. NOTE: Once the Save button is clicked, the description will be locked from editing. Please verify spelling and grammar before you save. The description will be visible to everyone who has access to the system. 1. General Tips for a Useful Ticket Report More Information on Writing Good Tickets Use an explicit structure, so your ticket reports are easy to skim. Ticket report users often need immediate access to specific sections of your ticket. Avoid cuteness if it costs clarity. Nobody will be laughing at your funny ticket title at 3:00 AM when they can't remember how to find your ticket. One ticket per report. Completely different people typically fix, verify, and prioritize different tickets. If you mix a handful of tickets into a single report, the right people probably won't discover your tickets in a timely fashion, or at all. Certain tickets are also more important than others. It's impossible to prioritize an ticket report when it contains four different tickets, all of differing importance to various people. No ticket is too trivial to report. Unless you're reading the source code, you can't see actual software tickets, 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. 2. How and Why to Write Good Ticket Summaries You want to make a good first impression on the ticket recipient. Just like a New York Times headline guides readers towards a relevant article from dozens of choices, will your title suggest that your ticket report is worth reading from dozens or hundreds of choices? Conversely, a vague ticket title like "install problem" forces anyone reviewing installation tickets to waste time opening up your ticket to determine whether it matters. A - 3

35 APPENDIX A Your ticket will often be searched by its title. Just as you'd find web pages with Google by searching by keywords through intuition, so will other people locate your tickets. Descriptive titles are naturally keyword-rich, and easier to find. For example, you'll find an ticket 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 ticket titled "Dragging icons doesn't paste". Ask yourself, "Would someone understand my ticket from just this title?" If so, you've written a fine title. 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 Ticket titles: 1. "1.0 upgrade installation fails if Chrome present" - Explains problem and the context. 2. "The installer crashes if launched on a Windows 7 system" - Explains what happens, and the context. (T3 Ticket 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. A - 4

36 APPENDIX B Export Data to Comma Separated Value (CSV) Format: T3 includes a feature to export the information included in the long format of tickets and other reports for use in Microsoft Excel or any other spreadsheet application that uses the CSV format. At the bottom of the page, right before the navigation bar, there is a button labeled [Export to CSV]. Once the button is clicked, the user will be prompted for a save location for the file. Figure B.1 shows the prompt to save. The following screen shots were captured while using Internet Explorer 8.0 and Microsoft Excel The prompts and screens may look different if using a different web browser or spreadsheet application. Figure B.1 Save Prompt The user clicks [Save] to start the process. The next step is to choose 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 B.2 shows an example. After entering a filename and choosing a location, the user clicks [Save]. B - 1

37 APPENDIX B Figure B.2 Example of filename selection To open the newly created file, the user must first open Microsoft Excel or some other spreadsheet application that supports CSV files. The following screen shots are from Microsoft Excel The users screen may look different if another version or software is used. Select the Data tab and click the [From Text] button as shown in Figure B.3. Figure B.3 Microsoft Excel Selections The user then locates the file saved above using window shown in Figure B.4. B - 2

38 APPENDIX B Figure B.4 Locate File User will have to change the Files of type option to All Files since the file is saved as a.cgi 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 B.5. Figure B.5 Text Import Wizard On the first screen of the wizard, click [Next]. On the next screen, shown in Figure B.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. B - 3

39 APPENDIX B Figure B.6 Select Correct Delimiter Another dialog box will open, as shown in Figure B.7, that will ask to where the data should be imported. Keep the default location and click [OK]. The data will display similar to Figure B.8. After that the user can manipulate the data just like any other spreadsheet. Some fields may truncate due to a limitation in Microsoft Excel with number of characters per cell. It is recommended that the user save their work after the import using the File, Save As The user will be prompted for a filename and extension. Figure B.7 Location Dialog B - 4

40 APPENDIX B Figure B.8 Created Spreadsheet B - 5

41 APPENDIX C 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. It is accessed by clicking the prefs link in the Navigation bar. The first tab is Account Settings, shown in Figure C.1. 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 T3. To change any setting, the user will be asked to supply their current password. The user should then enter their preferred password in both the New Password and Re-enter new Password dialog boxes. Once complete, the user can click the [Submit Changes] button. They will receive a success or failure message from the system. If successful, the user will receive a confirmation . The next tab is settings, shown in Figure C.2. The settings control how much a tester receives from T3. The system defines several types of users. However, T3 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 ticket. The assignee is the WAWF Staff Member assigned to monitor the tickets written against a specific application. It is recommended that a tester uncheck all checkboxes in the Assignee, CC, and Voter columns. The Page Footer tab, shown in Figure C.3, determines whether or not a tester has the My Tickets 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 C.4. This tab informs the users what they are allowed to do in the system. Figure C.1 User Preferences Account Settings Tab C - 1

42 APPENDIX C Figure C.2 User Preferences Settings Tab Figure C.3 User Preferences Page Footer C - 2

43 APPENDIX C Figure C.4 User Preferences Permissions C - 3