xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Using Remedy as a Defect Tracking Tool.

If you want to jump down to entering a ticket, click here
 

Logging on to Remedy.
	Find the Remedy 3.2 folder located under the Start > Programs groups. Click on AR User 32 to execute the program.
	The first screen will be a login screen. Enter the same User ID as your exchange ID, and type in your password. Ensure that all of the typed information is in lower case. Note that if this is the first time that you are logging in to Remedy, "password" will be your default password. Press Okay to continue and to log on to the system.
Performing a Query and updating existing cases.
	Once you have logged into the system, it will go to a blank screen. Select file from the top left corner, and then select "Open Query" in the drop down list. You can also click on the icon at the top of the screen with the blue question mark.
	A screen should appear that says "Select Scheme". There will only be one option to select, highlight it and either click "Okay", or press enter. The selection will read "ProblemManagement {Creston.stortek.com}".
	The Remedy System will log in, and it is possible that a screen will appear stating that there are no free licenses. Press Okay at this point to go into the query screen. Licenses dynamically rotate among users, and should you need to write to the database, the Remedy program will attempt to get a free license.
	A screen will appear which is titled "Query Window", and in the window will be all of the user's personal information from the Remedy Database. On the right will be two buttons, Manage Tickets, and Update Personal Info. Please click on "Manage Tickets" to proceed.
		Note, if you wish to modify personal preferences, or if you wish to change your password, you can select "Update Personal Information".
	Once you click on "Manage Tickets the system may give you a message that a "token" has become available. This is a license, as mentioned above. Press okay on that screen. The screen will display a preset form for enterring remedy tickets.
		In the bottom half of the ticket is a field named "Responsible Team". Press the button just to the right of the field and a list will come into view. Select IS_ICOAAces from the list.
		Once this has happened, a hidden lower section, customized for ICOA's needs, will appear. It is essential that you select IS_ICOAAces from the list or you will not be able to proceed.
		This is the query window. By entering a selection in one of the fields, you can narrow a search to find tickets.
			By selecting "Open" in the status field, you can look for all open tickets within the IS_ICOAAces team.
			Note that if you put in the Customer ID, or the last name of the user, the entire top of the screen will populate, which will allow you to log a call for another analyst, or track all calls originated by an analyst (including yourself).
			You can narrow your search further by placing information in the fields detailed below and in the User Guide for ICOA Defect Tracking within the Remedy 3.2 system. Suggested queries:
				Open in the Status window, your name listed in the Owner field. This will show all open cases that you own/are responsible for.
				Open in the Status window, Astea in the Request Type field. This will show all open cases that Astea is control of.
				Open in the Status window, hold in the Int. Status field. This will show all open issues that are holding for some sort of action.
		A limitless number of variations can be used when querying the system. If too much information appears on a query, narrowing the acceptable criterias (filling in more fields on the query form) can limit the number of "hits" found via the search.
	Once a query has found a case, or cases, double clicking on the case will open it into the Remedy Screen so that you can learn particulars, update the notes, or take the case.
		Note that the CSR number is a unique number assigned to each case. This can be tracked to speed the location of an open ticket.
		When modifying the ticket, you can take ownership of the call and show that it is an issue that you are working on by changing the Owner field to your name, and changing the Int. Status field to reflect W.I.P. or Work In Progress (an issue which is currently being addressed by the owner of the call).
		Updates to the case must be placed in the Call Log area, by clicking on the button to the right of the field. Changes are time stamped in this journal area, and anyone can read the library's history. You may only add contents to the library, you may not edit previously enterred information.
		To move the Remedy Case to a new analyst, simply assign it to them by selecting their name as the Owner of the case, place appropriate comments in the Call Log, and ensure that the Request Type reflects their group. You may change the responsible group by changing the Request Type. Any time that you make a change in the Case, you must hit Apply before it is saved into the database. Cancelling out of the application with an open case that has not been saved to the database will have no ensurance that your changes will take effect.
		When a case has been newly assigned to another group (performed by changing the Request Type to a new selection), it is necessary to change the Int. Status to "New". This will allow anyone from the new group looking for new cases to find this one.
		When a case is updated to have a new owner, a notification will be sent to the user that they have a new case assigned to them. The default notification is Email, but this can be changed by the individual by clicking on the "Update User Information" button described above.
		Anything changed in the case will be stamped in the Call Log library, however, it is essential that everything done with the issue is also described in the Call Log. Details such as when tests occur, how to reproduce a defect, reasons for delays, reasons for changes, detailed descriptions of actions performed with the testing or development all need to be fully documented so that a new Owner of the case can review all that has transpired with it. It also allows a new analyst to take a ticket and pick up where another analyst has left off if something prohibits the original analyst from completing or working on the issue.
Creating a case from scratch.
	Follow the procedures for getting into the query screen as above. Enter your last name/the last name of the person who identified the defect into the the last name field. (You can also use the Customer ID number, if you know it, to populate the field. If there are multiple users with the same last name, then you will be provided with a list of individuals to choose from).
	Once you hit enter after typing in the information, or when you select the correct name out of a list, then the information is populated within the Remedy Screen, including the discoverer's first and last name, phone number, work Email address, division, et cetera.
		Note that in this procedure, it will be rare, if ever, that you enter a Remedy Ticket in under someone else's name. Only when an individual does not have access, or when they are calling in remotely to you, will you log it in under someone elses. In either case, it may be a good idea to log it in under your own name so that you're the contact, and mention that the other individual is also involved by entering it into the Call Log library.
	After the information is filled in the fields, the button on the upper right corner of the ticket "New Ticket", becomes active. Click on this button.
	The screen will shift to a new ticket, and the CSR number will populate. This is the log number for this issue, and will remain the same throughout it's cycle. Log this number if you need to track this particular issue for one reason or another, though you can also find it by running a query with your name as the originator.
	Fill in a summary of the issue. This should be placed in the detail section of the Remedy Case. It is not possible for the information to be changed once the Remedy Case has been created. Included in this brief synopsis should be the area impacted by the defect (i.e. SECT Logistics, Financial, et cetera).
	Ensure that the ticket is assigned to the "IS_ICOAAces" Responsible Team.
	Severity will automatically be set to 3, and this should remain the setting until analysis has agreed upon an acceptable severity level for the reported defect.
	Enter the testing area wherein the defect was found by selecting the appropriate button in the bottom half of the form. (i.e. business, financial, rev. rec., et cetera).
	Set the Owner to the appropriate analyst if necessary. This should only be done if a single individual will have ownership of the case. If there is no specific owner to the case, or if it needs to go to a group of individuals, then do not set an owner for the case.
		You can set yourself as the owner of the case, if applicable.
	Record details about the situation in the Call Log. The analyst must enter the path they used to find the defect, the test scenario, the impact scope, and the result of the defect within this area for information.
	In the "Detail" field, the first line should be the path (i.e. DAKB), then the next line should be the server where the test was performed (i.e. Shannon), and then the brief description of the difficulty should follow.
		Also within the Call Log will be placed the Astea approval and the Analyst approval, both of which are required before the ticket can be moved into the development stage of the Defect Cycle. The entry should be small, something similar to "Astea-Approved" in the Call Log.
	Reassign the case to the next group by changing the Request Type and clicking on "OK" in the upper right corner, or by hitting the "Apply" button in the upper left. Note that this will save changes and close the case window, but you can run a query to gain access to the case and add more comments. After hitting OK, the "detail" section will only be changed to append a one line status comment to the case.
	Please follow the flow chart to determine which area to assign a ticket into. It likely will start in the Business Analyst Request Type, then move to the Test Coordinator Request Type, then to Astea or Internal Development, then to Retest, and if all goes as planned, it will end up back in the Test Coordinator Request Type.
		Once Regression Testing goes on line, the end result of the process will be that the ticket is moved to the Staging Request Type.