Any bug is a problem statement, illustrated with an example provided.
Yet the example is just a symptom. Has the problem really been gone?
Let’s ask questions. Let’s make bug fixing a truly collaborative work between programmers and testers.

Is it code change or configuration change?

• Code change – any fix, update, improvement, etc. in the code, including change of hard-coded data
• Configuration change – any change of configuration data in files, database, registry, etc.

What Business Functions directly affected by this change?

• Take notes of all Business Functions that use the affected code in the call stack.
• If they use it conditionally, find out the conditions.
• What Business Functions indirectly affected by this change?
• Business Function is indirectly affected if the change is not part of the business logic, for example, it’s a change in internal log, and it’s failure won’t cause a defect in business workflow or results.
• List all Business Functions that use the affected code in the call stack.
• If they use it conditionally, specify the conditions.

Root Cause

• What was the root cause?
• Was this code known previously working (or been broken for a while)?

System Integrity

• Does the fix apply to the all affected functionalities?
• If not, which ones were fixed and which ones were not?
• Are there similar code modules?
• If yes, do they have same problem? If yes, was it fixed?
• Does the change possibly affect performance, security, accessibility, or any other para-functional qualities of the system?

Testing

• Was it tested by developer(s)? How?
• If the developer(s) think that anything else in addition to affected functionalities needs to be tested, ask to kindly provide their suggestions.
• And – are they aware of any cases untestable in the test environment or the build?