A bug or defect in a software system is an error, fault, flaw or failure of the system that can cause any deviation from the intended use resulting in unexpected conditions.
The bugs are mostly introduced because of human mistakes, wrong interpretations, incorrect assumptions, lack of technical and business clarity but some may be generated by compilers by producing incorrect codes.
These bugs start unwanted processes and may extend a wide variety of effects affecting other systems, resulting in many inconveniences.
One important point related to bugs is that sooner we find them, easier to kill (fix) them. Finding the bugs early in the SDLC helps prevent what is known as defect multiplication.
Some bugs have relatively lesser effects and may avoid detection, but others are more serious in their effects and may cause a system to crash or freeze.
Some other bugs may cause breakage of security by allowing a malicious user to bypass access control system and interfere with the system and obtain unauthorized privileges.
Software Defects/ Bugs normally classified as per many criteria, most important ones are:
Also Read: Software Bugs Reporting Tools, Reporting Bugs
Bug life cycle is the lifespan of a software defect from the time it is born(identified) till it’s death (i.e. fixed and closed).
It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced.
Defect life cycle is related to the bug found during testing.
Bug transitions to different states in the Life Cycle which can be represented diagrammatically as follows:
[Figure: Bug Life Cycle]
New – Bug identified and raised on defect tracking tool then it takes the initial state as new.
Screened – After the defect is raised, an auto notification goes to the module lead then he screens the defect for validity and after reviewing all the available information he takes a decision to either assign it to self or any other developer. If he is not convinced of the validity, he would put it in feedback with appropriate reasons or he may ask for more information to understand the problem.
Feedback – When in feedback, discussion takes place between tester and developer and they come to a conclusion whether to go ahead with the fix or close the defect directly. Possible states from Feedback are Screened and then assigned or Closed based on the final decision. There could be many reasons for putting a defect in feedback:
Assigned – After it is decided to be fixed, it is assigned to a developer, and he analyzes and fixes the problem, gets it reviewed, performs unit test.
Implemented – After developer is satisfied with the solution, he changes the state to implemented and control moves back to the tester. It is for him to cross check the solution and verify the fix.
Verified – After the re-testing is done, either the fixed would have worked or failed. If it works, it is marked as verified and putting all the information related to execute test cases. If verification fails, defect is reopened with appropriate information and logs.
Closed – After verification is passed and all information put in the tool, it is closed and task is assumed completed.
You are almost there. Now that you know all about bugs , it time to get a peak into some of the most popular bug management tools. Keep on learning and keep on improving !!
Don’t forget to drop-in your comments or suggestions on this post to help us improve.