Defect Management

Defect management. Come let’s see, what is the Defect Life Cycle whose other name is bug life cycle. Like we had seen in tests basic terminologies that what Bug, Defect and Failure is? Now we will discuss the bug life cycle in detail. First of all let us know what is the requirement of bug life cycle? This is a bug life cycle. What is the need for this, this is also a question? Like what was the Software Testing Lifecycle was there. What was it there for? It was to see how the testing process would happen. Similarly the bug life cycle is there because when the QA, when he opens the bug, we will close it as well. From opening to the closing, whatever journey is there, we will discuss that here. Like you can see in the diagram when any bug will be detected, it’s status will come in new. Like a new bug found. When this bug will go to the development team the state of this same bug will be open. Like I found a bug, Login button issue. I will pass on the bug to the development team. That bug will be in an open state with him. When a particular bug will be open with the development team. It will be assigned to a developer. A developer named X will work on the bug. What will that developer do, he will fix it and send it back for testing saying that I have fixed the bug and now you can again test it. Now what will he do? It will come to the testing team. What will its test be? It will be a test. Because we have assigned the bug and he has rectified that bug. Now we will test that. What will we do by testing? We will verify it. In the verify process, we will verify and test the same bug. If that bug is verified there as per the requirements. So, everything is working fine. And we will close the bug, it is a very simple cycle. Now we will go back in the cycle. You can see that near the assign there are two arrows which are called Rejected or Deferred. Imagine that we have assigned the bug to the developer. The developer might reject the bug or deferred the bug. Now the question is what is the meaning of these both? Reject means the bug whose functionality we don’t know or it is such a functionality that is not a bug. Imagine that there is a pop up coming, we think that it is a bug but actually it is a functionality. In this situation the developer will reject it and how will he reject it, he will reject it with a particular reason. If he has rejected a particular bug, what is the reason behind it? Now the question will be what does deferred mean? Deferred means that we are aware that there is a bug in a particular version but we will fix this bug in the next version. Like there is Facebook and its 2.3 version is going on. Facebook knows that somewhere there is a bug, so what Facebook will do is it will fix this bug in the next version 2.4. Deferred means a known bug which we are going to fix in future. Now we will come again to test. Suppose we are testing, the developer said that these bugs are fixed, you test it. When we test it, the bug is not working properly or the particular fix is not working. What will we do then? We will reopen the bug and as soon as the bug is reopened, any particular developer who has fixed it, will get assigned to him again. Right? So, the bug life cycle is very easy. Now, we will go in more detail further to see how a bug is fed in a particular software and what all properties of the bug are added. This cycle that I explained, the same I have given here in a written format as an example. Here we have taken a software called Bugzilla. Bugzilla is open source, you can download it from the net. And you can even use it on your personal computer. So, First of all this is its main page, home page or landing page. Okay. When we click on new, a window will open where we will log the bug. In step 2 what happens is, whichever company where we are working, they must have set a particular field, that these 4 to 5 fields are required. What is the 1^st field? Product. Which product are we working on? That comes in it. Second one is the Component. It means which component of the product in which this bug has come. Is it an admin component, front end component, which component is it? Third thing is the Description of the component, what we are entering in the component, its description will be there from the start.  From the backend the QA lead or manager will feed it from the start. Fourth one is the Version; this is very important as this will go ahead and verify the version. Previously In which version this bug had come and now in which version it is coming? That also will be compared. Fifth is severity, how severe is the bug. Sixth is Hardware, on which hardware it is coming. Is it coming on PC, on mobile or on tablet? Seventh is the OS, is it in Windows XP, Windows 7 or 10 which one it is. 8^th is a summary, one small description or one short story, how the bug is produced. In which situation it is produced and attachment, keep in mind, whenever the bug is reported, it is very much important to have an attachment. So that the other person can easily understand where the bug has come and what is the particular format or behavior of the bug and at the end, we will click on submit bug. Now is step 3, in which we will see whichever bug we have submitted, how it looks. So, at the top thing that would come is the bug ID. Here a particular 1234, bug ID is given. The product that we had put in has come, the component has come, version, hardware and what will come after that? There are more things that we can put later. You can see the First one, the large text box, on the right hand side. I want to give some other good explanation. I want to tell 2 to 3 different ways from where this bug is getting reproduced. Even that we can give here. Second is the URL, suppose it is opening on a particular URL, we can even give that, white board, if we want to write something. Pay attention, a particular spelling mistake is happening here. If we want to highlight something. Keywords are very important in Bugzilla. What will happen with keywords, search will happen. May be there is duplication of bug is there. You have reported one bug of a particular login screen. The same bug is done by one of your colleagues. So, putting keywords is very important. If there are any login or button issues, login not working or button not working. Whichever keywords are there, we will add into it. Tags, you must have seen in the tags, which all tags come now a days. There are tags on social media or twitter, similarly, we will add the same tags here. Depends on, this particular bug, is it dependent of someone? Suppose it is happening after login then it is dependent on login functionality. After login this particular bug is opening. Block, is this bug blocking any particular process, that we will add to this. And at the end, 8^th, the attachment that is given below. We have to add an attachment, test case or steps to reproduce. Whatever we want to attach, there is screen shot as well there, we can add that here. So, what did we see? We saw a defect life cycle, bug life cycle and basics of Bugzilla.