Defect Management Process

Importance of the defect management process in software development teams

• Provide developers and other parties with feedback about the problem to enable identification, isolation and correction as necessary;
• Provide test leaders means of tracking the quality of the system under test and the progress of the testing;
• Provide ideas for test process improvement

Fields in a bug report

Bug ID: A bug number or an identification number makes bug reporting and referring to a bug much easier

Bug Title: A bug title is read more often than any other part of the bug report. It should say all about what comes in the bug. Also, the bug title should be suggestive enough that the reader can understand it.

Priority: Based on the severity of the bug, a priority can be set for it. A bug can be a Blocker, Critical, Major, Minor, Trivial, or a suggestion. A bug priority from P1 to P5 can be given so that the important ones are viewed first.

Platform/ Environment: The OS and browser configuration is necessary for a clear bug report. It is the best way to communicate how the bug can be reproduced.

Description: Bug description helps the developer to understand the bug. It describes the problem encountered.

Steps to Re-produce: A good bug report should clearly mention the steps to reproduce. The steps should include actions that cause the bug.

Expected and Actual Results: A bug description is incomplete without the Expected and Actual results. It is necessary to outline what is the outcome of the test and what the user should expect.

Screenshots: A Screenshot of the instance of failure with proper captioning to highlight the defect.

Why do defects have priority and severity?

• Priority is defined as the order in which a defect should be fixed. Higher the priority the sooner the defect should be resolved.
• Defects that leave the software system unusable are given higher priority over defects that cause a small functionality of the software to fail.
• Severity is defined as the degree of impact a Defect has on the development or operation of a component application being tested.
• Higher effect on the system functionality will lead to the assignment of higher severity to the bug. Quality Assurance engineer usually determines the severity level of defect.        Defect that has high priority and low severity: The landing page of your application, seen by millions of users a month, has a typo in your company name.                              Defect that has high priority and low severity: System crashes 25% of the time on start-up for an application that is being retired next week

When does a defect get differed?

The developer accepted the bug, but it is scheduled to rectify in the next build. In such situations, the status of the respective bug changed as Differed.

How to deal with inconsistence defects?

Inconsistent defect means which is not stable. The defect appears rarely not frequently. it occurs once in one of the scenarios.

If we try to reproduce that in the same way it is unable to reproduce. So for this type of bug, we can try to reproduce the defect in different scenarios and record the steps. We can analyse the bug with the help of application logs. We can attach the log while raising that inconsistent defect along with the screenshots.

When does a defect get rejected by a developer?

Rejection may be caused by a lack of detailed steps to reproduce the defect or a lack of test data. Inconsistent defects could also be rejected by developers. Testers should check the reproducibility and send the detailed information of the bug to developers.

What is a change request?

A change request is a proposal to alter a product or system, often brought up by the client or another team member. During a project, this can happen when a client wants to change or alter the agreed upon deliverables.

Change requests can also be initiated internally as well and can include things like changing or upgrading software.

Change requests that are inside the scope involve small corrections to an existing requirement. They usually have minimal impact on the budget or the rest of the team. On the other hand, change requests that are outside the scope take a considerable amount of time to implement and have a more sizeable impact on the budget.

Once a change request has been made, the entire team should be informed, and they can come to an agreement about how to satisfy the request without using unnecessary resources. There are three important questions to ask about any change request:

What is the change?

What is the benefit?

How important is it to you?

How does a change request get handled?

Request any supporting materials

You want the person who is making the change to be as specific as possible. Ask that person to put their request in writing and provide any supporting materials that might be helpful.

Have that person articulate why they are requesting this change and what the anticipated benefit of their change request is. This will help your team determine whether or not the change request is worth the effort.

Determine whether the change request is in inside or outside the scope

It is a good idea to consider what the scope of the change request is. You will want to consider all aspects of the project that will be impacted by implementing this change request.

If the request is outside of the scope, a lot of problems might end up popping up – going over-budget, for example. Or having to waste too much time on a project you’d never even agreed on.

Have the team assess the priority of the change request

Before the team implements any changes to the project, it is must to consider any possible risks. What is the expected benefit of the change being proposed? Is this change request the result of an actual need to respond to a change in the marketplace or would it simply be nice to have?

Approve or reject the change request

Different organizations have different ways of going about the approval process. Generally, a change request that will require minimal additional work can be approved within the team. Whereas a change request that would require a month’s worth of additional work may require executive approval.

Decide on a course of action going forward

If the change request is approved then the project deliverables will need to be updated. This can include plans and schedules, business process documents, and the requirements documents.

Once these updates have been made, the project manager can communicate the new course of action to everyone who will be impacted. Then you can delegate the necessary tasks to the people in charge of implementing these new changes.

Analyse a root cause of a defect

RCA (Root cause analysis) is a mechanism of analysing the defects, to identify its cause. Team brainstorm, read and dig the defect to identify whether the defect was due to “testing miss”, “development miss” or was a “requirement or designs miss”.

There is no defined process of doing RCA. It basically starts and proceeds with brainstorming on the defect. The only question which we ask ourselves while doing RCA is “WHY?” and “WHAT?”. This is very helpful to dig into each phase of the life cycle to track, where the defect actually persists.

We can start from the outer phase and move towards the inner phase of SDLC with “Why” questions

“WHY” the defect was not caught during the sanity test in production?

“WHY” the defect was not caught during testing?

“WHY” the defect was not caught during test case review?

“WHY” the defect was not caught unit testing?

“WHY” the defect was not caught during “design review”?

“WHY” the defect was not caught during the requirement phase?

The answer to this question will give you the exact phase, where the defect actually exists. Now once you identify the phase and the reason, comes the “WHAT” part.

“WHAT will you do to avoid this in future?

The answer to this “WHAT” question, if implemented and taken care off, will prevent the same defect or the kind of defect to arise again. Take proper measures to improve the identified process so that the defect or the reason of the defect is not repeated.

What is Defect Triaging?

Defect triage is a process where each bug is prioritized based on its severity, frequency, risk, etc. Triage term is used in the Software testing / QA to define the severity and priority of new defects