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