The following table lists the fields on the Change Request dialog box, explains their uses, and indicates which fields are required.
| Field | Required? | Description | Example |
|---|---|---|---|
| Status | Yes | For new change requests, set the Status field to New. The Status is changed to Open when the change request is assigned to a developer. | In this example, the status should be New. |
| Severity | Yes | Specify the seriousness of the problem. High severity items are usually associated with data loss or corruption, system crashes, etc. Low severity items are generally misspelled items and cosmetic errors. | In this example, the problem is comparatively minor (that is, if it does not cause the system to crash or lose data), so classify it as Medium |
| Priority | Yes | In most defect tracking systems, Priority is a multi-level choice (usually on a 1 to 5 scale). In StarTeam, however, it is a Yes or No choice. The priority of a change request is sometimes determined by the tester and sometimes by the developer. In most cases, it reflects the need to get a particular defect fixed before others. If the defect is catastrophic or prevents your team from accessing other major areas of the application, select the Priority field. | In this example, leave the Priority field cleared. |
| Platform | Yes | Indicate what type of operating system environment the defect occurs in. If the defect happens only on Windows 10, select Windows 10. In most cases, the defect will appear on all platforms. | In this example, set Platform to All. |
| External Reference | No |
Specify information received from outside the company, such as a note about a defect from an outside testing service or a customer. Currently this field is not used. |
In this example, leave the field empty. |
| Component | No |
Identify the component of the product in which the defect occurs. Currently this field is not used. |
In this example, leave the field empty. |
| Category | No |
Identify a sub-component of the product. It is used with the Component field to identify the location in which the defect occurs. Currently this field is not used. |
In this example, leave the field empty. |
| Synopsis | Yes |
Use to give a brief summary of the problem encountered or the suggested enhancement. Consider the synopsis to be a title for the defect. Note: The Synopsis should only contain information for one defect. If the reported defect uncovers or relates to another defect, the second defect should be written up separately and referenced to the first defect in the synopsis (for example, “CR #3109 also relates to this defect”). |
For this example, a synopsis might be: “Available fields disappear when using the Advanced Fields box.” |
| Type | Yes | If the change request is a reproducible problem in the software, select Defect. If it is a customer request or a feature enhancement request, select Suggestion. | For this example, select Defect. |
| Last Build Tested | Yes | Indicate the build number of the software in which the defect was discovered or last tested. If you are writing a change request, select the build number from the application (often found in the About dialog). If you are verifying or regressing the change request, and the problem still exists in the current build, change this field to the build number you are currently testing. | For this example, select the most current build number. |
| Addressed in Build | Yes | Indicate the build in which the fix first appears. In most cases, after the engineer fixes the defect, the field will be set to Next Build. This field changes to the correct build when that version is actually built. | For this example, leave the field empty. |
| Responsibility | No | Indicate the person who should act on the defect. Depending on the position of the change request in the change request life cycle, this person could be a developer, a QA engineer, or the person who first reported the change request. | For this example, either leave this field blank, or assign it to the lead engineer on the project, who will assign it to the appropriate person. |
| Addressed by | Yes | This field is automatically filled with the name of the person who originally wrote up the change request. It is not editable. | NA |
| Description/Steps to Reproduce | Yes |
Select the Description Tab. In the Description/ Steps to Reproduce field, enter detailed information about the defect. Specifically, the description should build on the synopsis information. The Steps to Reproduce information is the most important data entered in the change request because it provides a detailed step-by-step method of reproducing the defect. The more detailed the information, the more likely the responsible developer will be able to determine the cause of the defect and fix the defect. |
Steps to reproduce might look as follows:
|