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.
|