Being a software developer is painful at times, not only we need to clean our own filth (read bugs) but others as well.
The coding we do is merely some 10-20% of total work and most of the time its providing support doing enhancements and fixing bugs.
Fixing bugs is the most common phenomenon in the industry the bigger the company [you can blame any particular company, but its same for everyone] the larger is the bug pool. Like entropy of the universe, the total bug count of the software industry keeps on growing. [ I know its bitter but its a truth.]
All the modern programming languages are designed in such a way to either minimize the bugs
or in case of some errors how to find them easily, so those of you who dont like the TRY
ing and THROW
ing of Java, C++,C# better get used to it, because its for your own good.
Using log files is a good programming practice, it surely helps in saving a lot of time.
There is a dearth of good programmers in the earth. Mediocracy prevails through out the software industry[ the growing count of bugs is a proof].
Software engineering is a pain in the a$$ but it really saves your a$$ in the long run.
Anyway, you can always learn SE fundas, what this article is really is about bugs. What do you do when even after applying all the best practices [read software engineering] you get a bug in your module? Its very simple, you will have to fix it 🙂
Fixing bugs is an ritual in itself, it involves lots of steps. A typical bug cycle goes like this [its not complete but you can get an idea].
1. Customer/Developer/QA/ notices a bug
2. Assigns it to the relevant team, from there it comes to the actual developer, some one like me
3. The developer has to provide a Resolution for the bug. He tries to reproduce the bug at his location and sees
- If its a duplicate bug
- or if he needs some more information [ if its a customer bug, the communication with the customer is mostly through the Support team]
- or If it has to be deferred [that is fix it later]
4. Once its sure that the bug is there, the question comes, do we really need to fix it [ya there are times, like when a release of the product is at hand, its not really feasible to fix the bugs, usually these decisions had to be taken in the knowledge of higher authorities, i.e. managers]
5. Once its sure that the bug fixing has to be done, the developer provides the necessary fix, [that may or may not include code changes ].
6. Once the developers are done with their work, the bug is assigned to QA guys.
7. QA has to verify the bug, verfication means whether the original steps of reproducing the bug are still able to reproduce the bug or not. If not then the is the bug is understood to be fixed.
8. Once the fix has been verified its QA team's responsibility to close the bug.
9. Now the work doesn't stop here, there are several other steps involved before releasing this fix in the actual product. The fix could be related to any particular version of the product, based on that there could be various internal patches[ a structured bundle of the fixed files ].
10. Only after the thorough testing of fix, the patch is ready to be released, which is, it can be directly given to the customer or it can be bundled along with several such patches and included for the next release of the product.
This entire cycle of the bug is managed by the bug reporting tools. Usually all the product companies have there own bug reporting tools. Others mostly use bugzilla or a variant of it. I would suggest all the students reading this post to have a look on bugzilla.
Reporting a bug is also an art, a bug without a proper bug report is very difficult to understand hence the fix gets delayed. Here is a very good article about this.
There is also a nice pdf [4 pages only 🙂 ]on bug tracking basics by software testing and quality engineering magazine. It will help you to know some of the very common FAQs like what's the difference between a Developer and a QA.