Guideline: Creating and Maintaining Change Requests |
This guideline provides more details on how to create and maintain the change requests related to the test findings.
Main Description
#### Verify incident facts Verify that there is accurate, supporting data available. Collate the data for attachment directly to the Change Request, or reference where the data can be obtained separately. Whenever possible, verify that the problem is reproducible. Reproducible problems have much more likelihood of receiving developer attention and being subsequently fixed; a problem that cannot be reproduced both frustrates development staff and will waste valuable programming resources in fruitless research. You should probably still log all of these incidents, but consider identifying unreproducable incidents separately from the reproducible ones. #### Clarify Change Request details It is important for Change Requests to be understandable, especially the headline. Make sure that the headline is crisp and concise, articulating clearly the specific issue. A brief headline is useful for summary defect listings and discussion in the Change-Control Board status meetings. It is also important that the detailed description of the Change Request is unambiguous and can be easily interpreted. It is a good idea to log your Change Requests as soon as possible, but take time to go back and improve and expand on your descriptions before they are viewed by development staff. Provide candidate solutions, as many as practical. This helps to reduce any remaining ambiguity in the description, often helping to clarify. It also increases the likelihood that the solution will be close to your expectations. Furthermore, it shows that the test team is not only prepared to find the problems, but also to help identify appropriate solutions. Other details to include are screen image captures, Test Data files, automated Test Scripts, output from diagnostic utilities, and any other information that would be useful to the developers in isolating and correcting the underlying fault. #### Indicate the relative impact severity and resolution priority Provide an indication to the management and development staff of the severity of the problem. In larger teams, the actual resolution priority is normally left for the management team to determine; however, you might allow individuals to indicate their preferred resolution priority and subsequently adjust it as necessary. As a general rule, assign Change Requests an average resolution priority by default, and raise or lower that priority on a case-by-case basis as necessary. You may need to differentiate between the impact the Change Request will have on the production environment if it is not addressed, and the impact the Change Request will have on the test effort if it is not addressed. It is just as important for the management team to know when a defect is impacting the testing effort as it is to be aware of the severity of the impact on users. Sometimes it is difficult to see in advance why you need both attributes. It is possible that an incident may be really severe, such as a system crash, but the actions required to reproduce it very unlikely to occur. In this case, the team may indicate its severity as high, but indicate a very low resolution priority. #### Log additional Change Requests separately Incidents often bear out the old adage, "Where there's smoke, there's fire"; as you identify and log one Change Request, you quite often identify other issues that need to be addressed. Avoid the temptation to simply add these additional findings to the existing Change Request: if the information is directly related and helps to solve the existing issue better, then that's OK. If the other issues are different, identifying them against an existing CR may result in those issues not being actioned, not getting appropriate priority in their own right, or impacting the speed at which other issues are addressed.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.