Every developer has been at a point when a defect is found in software he has been working on, in fact a major part of every software developer is fixing bugs.
A software bug (or just “bug”) is an error, flaw, mistake, failure, fault or “undocumented feature” in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.
From Wikipedia - Software bug
The first order of business is to find what caused it, for that we need to discover what piece of code needs to be rewritten in order for the software to work properly. And so if we want to find a software defect all we need to ask ourselves is:
[From Paradesh Baata’s Blog]
Sometimes we can know the location of the bug by knowing our project very well but sometimes we have no clear idea of the exact code that could cause it.
Using simple practices and common tools can decrease the time spend on finding (and fixing) the bug.
In the ideal world when a new bug is entered into our code we would know about it - unfortunately for most of us we do not work in that place where each and every bug is discovered a few minuets after we’ve created it.
And so by having a server that that runs all of our project’s unit tests we improve our chance of catching defects soon and isolate the problematic code.
What if you project doesn’t have unit tests? what if the unit tests didn’t catch the bug and it was discovered by another developer, the QA department or even a customer – what can we do now?
Hopefully the bug report is detailed enough in that case we can try to reproduce it with previous versions of the code. When a version that don’t reproduce the bug is found – we know that the version after it has the code that caused that defect. Now we need to do some thinking and try to figure what is the difference between that version and the versions after it.
Even after we have an idea of where the defect is and what caused it most of the time we’ll still need to debug that code to verify our thesis. but by eliminating the places the bug isn’t we can reduce the time spent on finding it. There are some times when nothing helps and all we can do is debug our code line by line hoping to find the problem but by properly understanding our code and using simple elimination we can make it easier.
Labels: Thoughts, Tips and Tricks