|
Purpose:
|
To enter change request information into a tracking tool for assessment, management, and resolution.
|
Differences indicate potential defects in the Target Test Items and should be entered into a tracking system as
incidents or Change Requests, with an indication of the appropriate corrective actions that could be taken.
Sub-topics:
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. We recommend that you still log
these incidents, but that you consider identifying unreproducable incidents separately from the reproducible ones.
It's important for Change Requests to be understandable, especially the headline. Make sure the headline is crisp and
concise, articulating clearly the specific issue. A brief headline is useful for summary defect listings and discussion
in CCB status meetings.
It's important that the detailed description of the Change Request is unambiguous and can be easily interpreted. It's 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 ensures increases the likelihood that the solution will be close to your exceptions.
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.
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 as necessary. As a general rule, we recommend
you 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 isn't
addressed and the impact the Change Request will have on the test effort if it isn't addressed; It's just as important
for the management team to know when a defect is impacting the testing effort as it is to be aware of severity to
users.
Sometimes it's difficult to see in advance why you need both attributes. It's 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 it's severity as high, but indicate a very low resolution priority.
Incidents often bare 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.
|
