What is a Bug?


What is a Bug?


In Software testing, when the expected result and actual result is not matching, an incident needs to be raised. That incident may be a Bug.
.
                    

 ACTUAL RESULT ≠ EXPECTED RESULT = BUG/ ERROR/DEFECT


Bug is occurred by programmer's fault or mistake. And this has to be found by tester and get it corrected in order to maintain accuracy of software. For this Bug has a defined life cycle through which it has to undergo.

Life Cycle of a Bug:




The different states of a bug in the bug life cycle are as follows:

New: When a tester finds a new defect. He should provide a proper Defect document to the Development team to reproduce and fix the defect. In this state, the status of the defect posted by tester is “New”

Assigned: Defects which are in the status of New will be approved By (if valid) and assigned to the development team by Test Lead/Project Lead/Project Manager. Once the defect is assigned then the status of the bug changes to “Assigned”

Open: The development team starts analyzing and works on the defect fix

Fixed: When a developer makes the necessary code change and verifies the change, then the status of the bug will be changed as “Fixed” and the bug is passed to the testing team.

Test: If the status is “Test”, it means the defect is fixed and ready to do test whether it is fixed or not.

Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the software, then the bug is fixed and the status assigned is “verified.”

Closed: After verified the fix, if the bug is no longer exits then the status of bug will be assigned as “Closed.”

Reopen: If the defect remains same after the retest, then the tester posts the defect using defect retesting document and changes the status to “Reopen”. Again the bug goes through the life cycle to be fixed.

Duplicate: If the defect is repeated twice or the defect corresponds the same concept of the bug, the status is changed to “duplicate” by the development team.

Deferred: In some cases, Project Manager/Lead may set the bug status as deferred.
If the bug found during end of release and the bug is minor or not important to fix immediately
If the bug is not related to current build
If it is expected to get fixed in the next release
Customer is thinking to change the requirement
In such cases the status will be changed as “deferred” and it will be fixed in the next release.

Rejected: If the system is working according to specifications and bug is just due to some misinterpretation (such as referring to old requirements or extra features) then Team lead or developers can mark such bugs as “Rejected”

Some other statuses are:

Cannot be fixed: Technology not supporting, Root of the product issue, Cost of fixing bug is more

Not Reproducible: Platform mismatch, improper defect document, data mismatch, build mismatch, inconsistent defects

Need more information: If a developer is unable to reproduce the bug as per the steps provided by a tester then the developer can change the status as “Need more information’. In this case, the tester needs to add detailed reproducing steps and assign bug back to the development team for a fix. This won’t happen if the tester writes a good defect document.

 

Comments

Post a Comment

Popular posts from this blog

DIFFERENCE BETWEEN DEFECT , BUG, ERROR AND FAILURE

Image
DIFFERENCE BETWEEN DEFECT , BUG, ERROR AND FAILURE  DEFECT: If  difference exist  between actual result and expected result  and that difference is found by developer and  corrected by himself in the development phase then it’s called a defect.   Example if developer  has developed  a code  and while performing (Unit Testing) developed  found that the code is not functioning  as per requirement  then in tat case the issue occurred  is known as DEFECT. BUG: If testers find any mismatch in the application/system in testing phase then they call it as Bug. Example if the developer has done the development  and performed Unit testing of a login form then the module is sent to Tester for performing testing. In this phase if tester found that the client requirement is not matching with the  result of application then tester report it as Bug.  NOTE:  there is a contradiction in the usage of Bug and Defect. People widely say the bug is an informal name for the defect. ERROR If we can’t compile
Read more

Software Testing Life Cycle (STLC)?

Image
STLC(SOFTWARE TESTING LIFE CYCLE) It is a sequence of specific activities conducted during the testing process to ensure software quality goals are met. STLC involves both verification and validation activities. Contrary to popular belief, Software Testing is not just a single/isolate activity, i.e. testing. It consists of a series of activities carried out methodologically to help certify your software product. STLC stands for Software Testing Life Cycle. PHASES OF STLC : Requirement Analysis Test Planning Test case development Test Environment setup Test Execution Test Cycle closure What is Entry and Exit Criteria? Entry Criteria:  Entry Criteria gives the prerequisite items that must be completed before testing can begin. Exit Criteria:  Exit Criteria defines the items that must be completed before testing can be concluded. Requirement Analysis During this phase, test team studies the requirements from a testing point of view to identify the testable requirements. The QA team may in
Read more

SOFTWARE DEVELOPMENT LIFE CYCLE MODELS (SDLC MODEL)

Image
A software life cycle model is a descriptive representation of the software development cycle. SDLC models might have a different approach but the basic phases and activity remain the same for all the models. 1) Waterfall Model 2) V-Shaped Model 3) Prototype Model 4) Spiral Model 5) Iterative Incremental Model  6) Big Bang Model 7) Agile Model Waterfall Model The  Waterfall Model  was the first Process Model to be introduced. It is very simple to understand and use it. In a  Waterfall  model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.  The waterfall  model is the earliest  SDLC   approach that was used for software development. n “ The Waterfall ” approach, the whole process of  software development  is divided into separate phases. The outcome of one phase acts as the input for the next phase sequentially. This means that any phase in the development process begins only if the previous phase is complete. The waterfall model
Read more