Defect Management:

Here we are going to discuss the complete defect management process and defect life cycle that we follow in the defect management process. Apart from defect management, we will also discuss the change request management process as well.

Before starting the Defect Management process and defect life cycle, first, we will understand what is a defect and why defects exist in software.

Best Manual Testing Online Course

Our Trainer Profile 

What is a defect?

Whenever we develop a product it will have some futures and we try to implement these futures as per the requirements given by the client. It means that every requirement has its own expected result. Once the product is developed we need to test whether the implemented product is meeting its expected result or not.

So while doing testing if we see that one of the requirement’s actual results is not meeting with the expected result then we call it a defect.

In simple terms, actual result (developed product) should always meet the expected result. If it is not meeting the expected result then we call it a defect.

Why is software having defects?

In fact, no developer wants to create defects in software product/project/application. But we still get defects due to the below reasons:

1. Unclear / Poor Requirements
2. Misunderstanding/misinterpretation requirements
3. No sufficient time given to the testing team to test OR no sufficient time given for the development team to do unit testing

So now we understood what is defect and why software having defects, so let’s try to understand how the defect management process will work and its life cycle.

Where do we raise defects?

We raise defects in defect management tools. We have so many tools available in the market which are known as defect management tools. I am listing a few defect management tools below:

1. HP-ALM
2. TFS
3. Mantis
4. JIRA
5. Bugzilla

What tester should do when the defect is found?

Before raising any defect tester needs to perform the below activities:

1. Check if any duplicate defect exists (search in the title):

Here we need to check if any defect already exists for the same, I mean maybe another tester would have already raised the defect. This will avoid raising duplicate defects and saves efforts. How do I find if any duplicate defect exists? Every defect management tool will have a Search option where you need to search with your defect and it will list out all the existing defects as a search result.

   2. Put a valid title by which it can be understandable:

Every defect management tool will have Title OR Summary field in which you need to write a one-line summary about your defect. Let’s say you found a defect, where the system is not allowing you to log in even after entering the right user id and password, for this in the title/summary you need to write “System, is not allowing to log in even with the right user id and password” will your title/summary.

 3. Provide clear details in the description as much as possible

Here every defect management tool will have a description field and in this field, we need to provide detailed information along with test steps. Let’s take the above defect as an example and you need to provide details as below in the description field:

“When I enter my correct user id and correct password in user id and password filed system is not allowing me log in. I am getting an error message stating “Please enter valid user id/password” even after entering the right user id and password”

Our Trainer Profile 

Best Manual Testing Online Course

 4. Include requirement reference number in each defect by which it makes easier to activate

Every requirement will have its unique reference number in non-agile models but when it comes to agile model you will user story number. If you mention these requirement reference number OR user story number it makes easier to activate the defect.

 5. Attach screenshots and video if applicable to understand easily

It is always strongly recommended to attach a screenshot OR video of the defect so that it makes it easier to understand the defect to the developer. Let’s say you found a defect where there is a spelling mistake in the error message. Capture the screenshot of the error message and attach it to the defect. Every defect management tool will have an option to attach files to the defect.

 6. Provide detailed steps along with test data used to reproduce the defect

It always recommended providing detailed steps and test data in every defect you create. Let’s take same above defect where you are not able to login even with valid user id and password. So here you need to provide detailed steps on how to reproduce defects and with test data that is used to find defects. Test data plays a major role sometimes. Let’s take the same above defect you are not able to log in because the user id you used is locked in the back end due to which you are not able to log in. So here it is not a defect and it’s an issue with the test data you used. If you log in with another user id and password system is allowing to log in successfully.

 7. Use correct severity and priority of the defect as defined (consider workaround  before doing this)

While raising defects you need to make sure you need to use correct severity and priority. I will explain about severity and priority below.

What are Severity and Priority?

Severity means, how a new defect is impacting to business/end user is going to decide this

Here I am listing few defect severities below:

Critical: If the defect is a blocker ( mean not allowing to proceed) OR having huge financial etc..

High: If the defect is related to functionality and this defect can be considered as a High severity

Medium: Not a functional issue but a minor issue and no impact on the functionality of the system.

Low: If a defect is related to spelling mistake OR alignment OR Capital letter is displayed instead of small letter OR One field is overlapping on another field etc.. can be considered as a low defect.

Priority:

Based on the urgency of fixing the defect is going to decide priority.

Here I am listing few defect priorities:

P1: We need to fix the defect immediately OR as per the agreed timelines with the client

P2: We need to fix these defect as soon as all P1 defects are fixed

P3: We need to fix these defects as soon as all P2 defects are fixed

P4: We need to fix these defects as soon as all P3 defects are fixed

 

Defect Management Life Cycle or Defect Life Cycle:

Here we will try to understand what is defect life cycle nothing but what will happen once the defect is raised is known as defect life cycle

Below are the deferent defect status/life cycle

Proposed / New: This is the status when the defect is newly created by the testing team

Triage:  Testing Lead / Defect Lead reviewed defect and ready for discussions with stakeholders.

Active: Development Lead / Project Lead agrees for activation of the defect

In progress: Individual developer started working on it

Resolved: Individual developer fixed and assigned to the tester to re-test

Re-Open: Tester re-opens the defect as it still not working even after the fix

Deployed: Deployed to test environment and ready to test for the test team

Rejected: Rejected by development team stating not a valid bug (like a duplicate bug, not reproducible, working as expected)

Closed: Tested by testing team and closed (working as expected) or agreed with the rejection reason

Change Request Management:

We completely understand defect management and now let’s try to understand change request management.

As the name says change, it means that the tester raises some defect but it is not a defect as it is not given user story OR in the software requirements document. But it is a good future to have. Let me give one example, let’s say you are working on a banking application and your testing the future of transfer funds. Here tester feels that if have video demo on how to transfer funds it will be easier to new user to understand how to transfer funds. But developer rejects this defect as it is not given in the requirements OR user story. Then we reach to the client requesting do you want us to implement this future? If a client says yes then we charge to the client for implementing this future. Let’s say it will take 100 hours to implement this future then we charge the client for 100 hours. I hope you guys got the difference between defect and change request

Our Trainer Profile