It may take you much effort to fix a bug. The fix may not be reliable. How can you avoid this situation?
- Try to understand the scenario or use case. Ensure that you and the tester are talking about the same thing and agree about the missing or incorrect elements by comparing the final user interface with the original approved use case or user story.
- Try to reliably reproduce the bug. It is okay if this may not be successful.
- Try isolating the bug on the same environment by using specific, smaller data and settings. It is okay if this is still not successful.
- Search for an existing solution using the error message, the library or framework name and version, and the operating system name and version. This can save us a lot of effort.
- Try to understand all the concepts in the error message.
- Debug and log messages to identify the exact location of the source code that causes the issue. In order to to this we need to do the followings.
- Identifying the flow of the data, i.e. the use case, the entry point and the exit point.
- Trying to understand the programming language syntax. Do not guess anything.
- Trying to understand the purpose, inputs and outputs of a library function. Again, do not guess anything.
- Trying to understand the data structure and a part of the database schema related to the use case.
- Trying to review some values inside the database if possible.
- Trying to understand the concepts, algorithms and architecture related to the use case.
- These steps may be done in parallel and iteratively.
- Guess a cause of the problem based on the information retrieved in the third step.
- Try to isolate the issue, i.e. try to reproduce the issue using specific code and unit tests, if possible.
- Search for or propose a solution for the cause, i.e. propose a fix.
- Test the fix.
- Repeat from Step 5 to 8 if needed.
(Visited 40 times, 1 visits today)