The Art of Bug Solving

As a software developer, when starting to solve the bugs reported by the testing team, the fastest and most efficient way is to follow a systematic approach, meaning to go through a predefined steps. The ones I follow are:

Step (1): Try to reproduce the bug, meaning to go through the steps the tester mentioned in the bug description to see if you will face the behavior the tester faced before.

 - If it can't be reproduced again, this means that the bug ((( may not be))) valid and the tester may have gone through a wrong step to validate the functionality of the software. In this case, assign the bug again to the tester attaching your test report. 

 - If you could see the same behavior, this means the bug ((( may be ))) valid and you have to investigate further in the issue. Proceed with Step (2).

Step (2): Review the source code against the requirements.

 - If you find a part of the code that doesn't match the requirements, and solving which solves the problem, then you have solved your bug. If it doesn't solve that certain bug then you have found yourself another bug.

 - If none of the above is the case, proceed with step (3) .

Step (3): Review the testing steps against the requirements to make sure the behavior the tester is expecting matches the requirements. If you find yourself expecting a different behavior that the tester should have expected instead, then apparently the bug is a system requirements bug. In this case the bug should be assigned to the system team.

Notes:

Note (1): The step of reviewing the code may have many other advantages than just finding the cause of the reported bug, supposing the code you're debugging is not yours. Other advantages are:

- You get exposed to different coding styles and practices. That helps you improve yours.

- You actually might find other undetected bugs.

Note (2): In step (1), if the tester assigns the bug back to you insisting there indeed exists a bug, proceed with Step (2).

Note (3): In all of the above, I am assuming the use of an issue tracking system.

At last: You might think of bugs in code as a totally bad thing, but actually working on solving bugs would teach you in a short time things you would have taken much longer to learn in normal code writing.

I try to write quality code the best way I could, so mostly I work on solving bugs in other people's code, and I must say I have learned so much from solving those bugs. It exposes you to different coding styles and practices. It makes you dig deeper into theory and better understand the requirements. And makes you avoid the same mistakes in the future.

Any additions or opinions are welcome.

#software_tips_Alsayed_Alsisi