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?