Defect Life Cycle: Essentials of Software Testing

Just like the life cycle of a program, a defect cycle occurs from the time a defect is found to the point it is fixed. To properly handle projects, you not only need to know how to deal with development and release, but you also need to know how to handle defects. The defect life cycle is a part of risk management, which has several sub-topics to cover.

Understand how software is tested at Udemy.com

Desk-checking is nothing but reviewing. Anytime you write a document, we’ve gone through the formal review process, so desk-checking is another word for reviewing, it is a verification technique. Most of the time this means a peer review or reviewing your own work.

Basics of defects

A defect is nothing but, any deviation from the expected value. So let me ask you a question- when do we encounter defects? To be more specific, at what phase of testing, in what phase in the SDLC software test life-cycle, do we encounter defects? Predominantly, in the test execution phase, but that doesn’t mean it’s limited to the test execution phase. We had several rounds of reviews, as in, when we move on from the testing phase, and anytime you find that there is something not quite right with the document, something that’s not quite right with the requirement, in that case also, most of the time, defects are raised. A defect is not specific to the execution phase. Although, it is predominantly where defects come into picture. No matter how minor the role is until test execution, defects do come up in every phase of the testing. Basically one thing we need to get straight is, defects are going to be in every phase of testing.

Let’s propose another question. You’re in the requirement analysis phase, and found the requirement that is just not right and you cannot test it, so do you raise a defect at that time? The answer is, you could, depending on the defect management process, product protocol, that you have defined in the project, you could raise a defect anytime you find a difference in the expected and actual, you should raise a defect. That is not just confined to the application; it could be in a document also. Say you are reading your functional definition document and you found that something’s wrong with it, go raise a documentation defect and assign it to the person concerned. The point of raising a defect and tracking it is the only way you can make sure that a change you would want to happen is actually address, so you first raise a red flag. How do you do it? By creating a defect. In every phase of testing, it could be requirement errors, or it could be an application error. The documentation requirement, or review comments, everything could be a defect. Again, it depends on the extent of damage a certain defect will do. Say if it is just a spelling mistake, you might as well just talk to the person who created the document and have it fixed. This is the place where you need to use a little bit of your judgment to make sure how severe or not severe a defect is.

Let’s say we are in the test execution phase, what kind of errors you will encounter? What do you think the kind of defects you will come across in a test execution phase?

When you’re executing a test, one of a couple of things can happen. Either the requirement is implemented incorrectly, or the requirement is missing, or there could be an extra requirement. Let’s take the example of Facebook. According to the Facebook guidelines, if it says that a user has to be a Yahoo.com or Gmail.com user to be able to create a Facebook account. If that is the requirement and if it implemented incorrectly, what happens? The person who is a Hotmail user, he might be able to log in, so that is an incorrectly implemented requirement. You can also have missing requirements such as no logout button.  This is an example of a requirement that is completely missing in the application to test. When you get the application and you are running your tests, you’ll see that something is not implemented at all, so that becomes a defect. If all you see something extra, say there are supposed to be three links on the page and you see that there are four instead of three, even that is considered a defect. So, anything other than what should be present or anything other than how it should work, all kinds of differences, whether it is having something extra or not having the minimum, everything comes under a defect.

Find out what it means to find a software defect

Code errors, such as syntax errors, are usually caught by companies. When it comes to a system testing phase, it is mostly around the functional requirements. Basically we are trying to make sure that the application adheres to the specifications. So in this case, any extra specifications or anything missing or some things incorrect, everything comes under a defect, basically.

You use test cases to identify a defect. This gives you an expected result and an actual result and you can compare the two. Can you find a defect without a test case? Yes, you can actually find a defect during your exploration of the application, while you’re experimentally testing. Or you could just look at an application that might be right there in front of you, and you’ll be able to just find it. These are a couple of the ways you can identify defects.

Best practices: Accurately identifying defects and relying on peers

As soon as you think that something is a defect, what do you do? Is there anything that you need to do before you actually log it? Research and try to imitate. As soon as you get a defect, a good practice is to talk to your peers. There are a couple of reasons for this. First reason is because you don’t want to raise an incorrect defect. Why is that? With your test execution case , whatever the timelines that we provide, they include the time taken to execute the test, plus the time taken to log defects, plus the time taken for other maintenance activities. So, when you’re raising a defect, you’re actually spending some time on it. That means the tester is spending some time on it. Then you assign the defect to somebody, which is somebody in the development team. So when you raise an incorrect defect, the development team will have to spend some time researching on it, and then tell you that it is not right. This is just an additional step to be sensitive about another person and team’s time and effort. Also if you keep raising incorrect defects, it’s going to reflect very badly on the test team’s knowledge about the application. So keeping those things in mind always, once you get a bug, check with your team members. Always check with your team members, if you can, go back and check in the documentation. Even then, if you think that something’s wrong, if you can, try to talk to your developers.  Get the basic idea, get an understanding or get an agreement on the fact that something’s not working right.

The next step is to make sure the defect was not already raised, make sure it’s not a duplicate. These duplicate issues are a waste of time and they reflect very badly on the test team’s coordination. Always make sure that when you encounter a defect, go and check in your defect log if that defect was already logged.  If it is not logged, only then make sure you log. So the third step is to log it.

How do you log a defect? What does it mean when you say, “Logging the defect?” “Have a record”, yes. And “create a defect report.” Let’s assume I’m creating a defect report, what do you think should be the phrase? First of all, every defect has to be identified uniquely, so it will have a defect title. The defect log item should have a name, a description, where it occurred, a snapshot and a severity. Another important step that we need to include is the steps to reproduce. Steps to reproduce means the exact sequence of operations that you performed on the application that actually lead you to this error. So these steps are in a way important in the sense that when this developer starts to work on this defect, he needs to know exactly what to do to recreate that error. Steps to reproduce are an important part of defect description, and the more elaborate you can be the better. So when you’re including steps to reproduce, some of the common guidelines are include all the steps right from login. If at all, in the compose mail part, if you found an error, start with logging in. Start logging in, start going to the compose mail, do the exact steps, so basically include everything from the start to the finish. Include the test data. Also include test data you used. So make sure that you give all the information necessary. If you are using a particular browser, all the environment specific details also, you will have to include, browser details and all the other information.

Assigning defects

Next, who do you assign it to? As with the case with any other process in the test cycle, a defect management process also has to be first created during the test plan time. When I say defect management process, it includes decisions like what does seniority mean and who to assign defects to. If you have ten defects and if you have five people in the development team, who do you assign it to? How do you know who should you assign it to? All these decisions have to be made during the test planning phase, or probably if it’s done later, all this information has to be documented back into the test plan. So your test plan is the direction, the map, where you will get all this information about who the defect should be assigned to and what are the different states of the defect? We’ll see what it needs, but let’s just talk about the general procedure first.

Defect management is an important part of test plan. Basically, a defect description would include: defect ID number, the defect name and type, description, the source of the defect, priority, severity, the status, we’ll talk about the defect status in a little bit, date and time, detailed description, components of programs, clean print, state of origination, person assigned to research and curing the defect. So basically we’ve covered them all. This is the information that every defect encountered should contain, when you are trying to log it.

So let’s come back to the explanation here. Basically the defect management process, from whatever the tester is doing, that’s called defect discovery, because we are the ones who find the defect. Defect discovery includes: finding the defect, recording the defect, reporting the defect and acknowledging the defect. Basically if you are first to find it, you record it, you report it and then you will acknowledge it. That means you raised a defect and you put the right state to it, you’ve assigned a state to it so that you can track its progress. That is the defect management part of the tester.

As soon as you get a defect and you’re working on it, there is something that we all need to do, which is the root cause analysis. Ideally this is not the job of a tester. RCA is a very integral step of the defect management process, but ideally we are not expected to do any root cause analysis. Say if at all something is not working, nobody expects you to know the exact line of code where something fails for you to get that error.  Nobody expects you to do that. But with time and experience, if you’re continuously working on the project for a long time you’ll be able to tell, depending on the trends, or depending on the type of defects you’ve been encountering so far, you will be knowledgeable enough to say, What part of the application created this bug and why does this happen? It could be a database overflow, it could be that some company, some server might be down. So you will be able to tell what went wrong, for you to encounter the defect. So if you can get to that state of root cause analysis, and exactly put the reason why you think that that defect has occurred in your defect description, that will be a definite added advantage, and that is the direction in which all the testers need to be thinking, because just executing and finding a defect, is something anybody will do. So root cause analysis is something that we need to have our minds on, and we should be able to tell. Anytime you encounter a defect, other than looking at how to reproduce it, and how to log it and things like that, which are very basic, which are very important, other than that, when the defect goes through a resolution, try to understand how the defect got resolved. Try to understand what made the resolution happen so that next time it comes up, we will know the exact reason why it failed.

Learn all about testing software and being a QA tester

So root cause analysis is an important part. If a tester can do it, that’s a definite value addition to the team.  That’s the next step. There is a little bit of difference between the severity and the priority of these values. Severity is nothing but the importance of the feature. Priority, say if a defect has come up, again let’s take the example of the logout button not being there, the logout button is not there. As a requirement, having the logout button is low severity. This is a low severity because if I’m not able log out, it is practically not stopping me from doing anything on the site. Take the example of Gmail.com, if I’m not able to log out, that doesn’t mean I cannot send an e-mail, that doesn’t mean I cannot check my e-mail, that doesn’t mean I cannot create a group. Basically, the logout functionality is of low severity. That means it is not very, very crucial for the site to function. But then, having it fixed, is it not a priority?

When we say we are functional testers, we are more concerned about whether you are able to use the site or not. When you are looking in that way, not having a logout button does not necessarily stop you from doing anything. From a functional perspective, the severity is very, very low, but then, from a security perspective, from an overall experience of the site perspective, it is very, very high, so this needs to be fixed right away. In that case, the priority becomes high. So severity and priority are slightly different from one another. Severity is nothing but how important is the function to the site. Priority is nothing but, how soon should you fix this bug? Priority is all about– sometimes, even though there is a low priority, low severity bug, if the priority is high, that means the developers are going to work on it right away. It’s a kind of indicator, so that developers know how quickly they need to start working on a bug.

Once the defect is created, how do you think the communication goes to the developer, how do you think he knows that a defect has come up and they need to work on it? There are a couple ways this happens. In most of the projects, defect management or defect reporting, there are specialized tools to do that like Bugzilla or QC, most of the companies, most of the projects they use are automated to– they use a tool for defect management. If not a defect management, generally if not the tool, reporting a defect. You log the defect– how do you report a defect?

Either you do it through a tool or, but it also depends on the process that you agreed on. For instance, email is sometimes used but it’s not a good method since you could then send dozens of emails a day. Another method, if at all it is a manual tracking project. Usually this is a meeting between the representative from the test team and the representative from the dev team. So basically what they do in the different meetings is they go over each one, and they talk about it and they discuss it. Usually the test team, they’ll explain how they encountered the defect, what data they used and they will– if it helps, they will show a screen shot, and things like that. Once you raise a defect, one of these things could be true – the development team might decide that the information that you provided in the steps to reproduce and this whole defect log is not enough. For them to start working on it they might need more information. That is one thing. If they need more information for the bug, you again are going to come back to tester’s plate, and then the tester will have to include more information in the bug log and the defect log. Or, they could decide that it’s a duplicate data.

Again we are testing things, we are humans. No matter how much we discuss on it and no matter how much we try to make sure that we don’t log anything that is actually not a defect, sometimes it might happen that we do log duplicate defects. So they might send it back and say it’s a duplicate defect. Or they might say that it’s not reproducible. Once the development team takes it, they just execute the same steps, for one reason or the other, the bug might not come back. So at that time, they are going to change the state of the defect to not reproducible, and the defect is again going to come back to the testing field. Sometimes we might have thought it’s a bug, but they might say it’s working as intended. In all these cases, the defects, the defect gets rejected and it comes back to the tester’s plate. Sometimes you just have to close the defect. For example, if it is working as intended or if it is a duplicate defect, we just have to close it. And if at all, those statuses are again registered. If not, we’ll have to provide more information or provide more steps to reproduce the defect and again send it back to them. Or in this state, if they do think that once the defect comes to them, they realized it and they decide that it is not going out as part of this cycle and if it is, for later, they might say this before. These are the initial screening steps the development team will do before they even start working on it.

Once it passes all these steps and when it is a legitimate defect that they’re going to work on in the current release, that is when priority comes into picture. They’re going to pick up the defects based on the priority, only after all these decisions have been made and all these conditions are ruled out. So that is what happens with the development team. So the developers part over, defect management cycle is: they prioritize the fix, they schedule a fix, they fix the defect, and then, we’ll get our resolution. So let’s write down the steps, developments team work is.  These are the activities that development team performs. And the testing team: they find the defect, they record defect, report, and they acknowledge. The activities that the testing team performs are called different discovery steps, and the activities that the development team perform are follow defect resolution steps.

Is a sign-off on a defect verbal or written? If at all, it is going through a defect meeting, like the dev team and the QA team are meeting up and they’re discussing it then and there, then when a decision is made right away, it is not verbal, basically when a verbal decision is made, you will have to always come back to the sheet and update it. It is both verbal and written in the sense that all your differences, it is not done through a tool. If it is a tool, what you do is, you directly update the status in the tool and the tool will track its history for you. So it’s not really verbal. In any case, you will have to document it and share the results with the rest of the team. As with the test reporting, we talked about it on Friday, the testing status, like how many test cases have you executed and what’s going on, just the way you shared that status with the rest of the team, you will have to share the  defect status also with the rest of the group. So that is probably a way you can say to sign off. So that’s what this acknowledge means. When you acknowledge, either you say that it’s a bug or it’s fixed or it is still open or whatever. When it comes back to you, you basically acknowledge it as being fixed or not fixed. So yes, that is a test teams job. So this is then basically the defect management process. Again every team has its own method. Every team follows certain guidelines, every team has rules as to who needs to be notified and what all information needs to be there in the bug report. So all this information, are usually updated into the test plan, and any time a customer needs any confirmation or any questions that we might have, test plan is the place to look for answers.

Sample runthrough

Let’s go through a sample defect. We’ll just try to put in one defect, we’ll just try to log one defect, and then we’ll move on to the defect life cycle. Again, defect ID, defect description, steps to reproduce, severity, the class of the defect, and the type. So let’s create it. Go to the Facebook site. Again, this is not a defect actually, it is working as intended but let’s just assume that this is not how it’s supposed to. When I choose February, let’s say the requirement records should display only 29 days. Other than that, it’s displaying 31 right now, so let’s log that as a defect. Defect ID, I’ll just put  01, or 1, defect description, Facebook homepage displays, steps to reproduce.

The application apparently displaced, 31. I will just say this is low priority and again low severity. And the class is nothing but, this is an identifier that will tell you if it is a missing requirement, wrong requirement or extra requirement. So what does this come under? Is it missing, wrong, or extra requirement? Is there any other information that I need to put under, steps to reproduce? I can include, used Google Chrome as developer, and then this happening at – location, homepage, sign-up.  So I would say this is a requirement that is working incorrectly. This is an incorrect requirement, and the type a code defect, positional defect or a functional defect? Typically all these fields exist, if it is a code defect that is for unit testing, so let me list that – code defect, functional defect or a positional defect. So, typically in the system testing phase, we always put it as functional defect. This is just to report. When we talk about how we track it, how we assign it, and who we assign it to.

The steps to reproduce are basically the guidelines. Consider it a test case that you are giving to the developer, think of it that way. Because if you don’t let the developer know exactly what you did and how you got to the error, developers don’t have access to our test cases, even if they do, for a typical project you will have somewhere close to 1000 test cases and neither do they have the time nor the interest to go through every test case so you will have to provide the exact steps that caused this error to happen. So yes, unfortunately steps to reproduce is not optional and it should be as detailed as you can. You can err on the side of giving more information, but less is never acceptable. Yes, it is actually for the benefit of the development team and sometimes bugs are not just reviewed by the development team, the whole project team, sometimes the clients want to review what kind of bugs are happening. In that case, for somebody who is not very computer savvy, if they want to recreate that bug, you want to make sure that you put in as much steps as you can. To reiterate, always the steps to reproduce is the most important part of your defect description, and it’s okay if you provide too much information but never be less. This is how a defect is basically reported.

As a general practice, this is just a tip for those who are using an automated tool like QC, if you encounter bugs and it is something that needs to raise a red flag immediately, then go ahead and print it directly in your tool. If not, take some time and write it down on an excel sheet, review it one or two times, again follow the steps I said earlier like – do a peer review, make sure that you are not logging the duplicate bugs. Make sure about all these things and raise the defect later on once you are confirmed about all these things, because most of the times, in an automated tool, the tester will not have an access to delete anything. So in that case, you don’t want to put in information into a tool which is not correct and it’s again, a bad reflection on the peer team. So these are some things to make sure that you’re putting in the right information everywhere.

Defect lifecycle

So this is basically about defect management and defect reporting. So now comes the defect lifecycle. Again different states are very different for different projects. So basically actives, who are all involved, in a defect lifecycle? Who do you think is involved in a defect lifecycle? Any thoughts, team? In a defect test lifecycle, basically test your sounding board, we test the QA team. Who else is involved? Development team, and the project team. Maybe not directly, but indirectly the project team is also involved. Sometimes the environment team, if it is an environmental issue. So we’ve got all the actives. Again, the states that you want to assign to a bug are again, different for different teams, but we’ll just see a general outline.

As soon as the defect gets created are reported, you need to record them. When do you do this? When you encounter a bug. Once you encounter a defect, typically the state is that it’s open. At this stage, the action that you perform is assign that defect to the dev team representatives. Typically, the teams are not just one person. In a development team, there might be five or six developers and you don’t know who was the one who developed the module that you’re working on. Even if you do know, you don’t know if you can assign it to him because you don’t know what kind of plan he has for his day or what is his bandwidth with respect to working and all. Usually, the dev team lead or a representative from the dev team is chosen, so all new bugs are assigned to him. And then, the dev team lead will analyze the data. Who does this? The QA team. The defect analysis is done by the dev representative, and here, he decides on one of these states. He can decide that it is non-reproducible, he can decide there’s not enough info, he can decide that it’s a duplicate, or he can decide that it’s not a bug. He can decide that it is differed in a sense, or he can decide that it’s a legitimate bug and then it moves to a side. So here a specific developer to work on here, defect is assigned. So this bug is now in the plate of a specific developer. If at all it is not reproducible, not enough info to duplicate, in case it’s not reproducible or not enough info, again it goes back to the QA team and the state will be open on it…or you can have a non-reproducible state. Again this is dependent on your current project and if you choose to keep a non-reproducible state that is your choice, otherwise you can just keep it open. So all your decisions are again documented in the defect management section of the test plan. If it’s not enough info again it goes back to the QA team, open all, not enough info, duplicate.

Either it’s facing the state of duplicate or it gets closed. If it’s not a bug, close or again, you can have a state of not a bug. The report is a separate step, which means the bug is not going to be acted on in the current place. So it gets assigned. When it gets assigned to the development team, there might be another intermediary state called work in progress. So when it says work in progress, the specific dev person is still involved with this bug. Once he is done, he finds a resolution, he can put it to resolved or retest. Again, the QA team needs to check on it and make sure that it’s been really fixed or not.

The next state it goes to is, resolved and retest. So here they are in charge of QA team. So what happens when we retest it? What are the phases the bug can go into? One of the two things can happen. When we are retesting it, the bug might be fixed or the bug might not have been fixed. If the bug is not fixed, you reopen it and again assign it back to the bug team. If it is resolved, the state goes to closed. In that case, nobody is there in charge. These are all the states that a bug can go through. This is a bug life cycle, from the time it opens to the time it closes.

It doesn’t end here! Try this course for expert software testing training and learn quickly today!