Software Defect Life Cycle - 

Problems, Solutions and a way to bring more business

 

Learn how software defect life cycle can bring more business

 

The defect is a deviation from the actual requirement, ranging from the background color to an unexpected flow. A defect can be an error or a bug, which was missed at the initial requirement gathering, or functional or might be related to User experience. To remove that defect lets understand the “defect itself has its own defect life cycle starting from its creation to closure.”

 

Before reaching the software defect life cycle, according to me, there is an initial requirement gathering stage where maximum defects can be fixed or can be analyzed. All it needs is proper communication and understanding of the product between client and developers/BA and other stakeholders.

 

Interpretation level of different departments and the output -

 

The below image summarizes the whole story from the requirement gathering stage to the final delivery of the product. i.e., as we can see at the process/requirement stage how the customer explained, how the project leader conceptualized, how engineers and designers worked on designing and writing code, and what the customer needed.

 

The cost of defects fixing rises from its requirement gathering phase to the final product.

 

different-perspective-on-requirements

 

from the above image, we can conclude that 

It is elementary to fix the defects and to be cost-efficient by working on analyzing defect from the initial stage of gathering business requirements.

 

Defect Life cycle process-

 

Now fix defects by following this defect life cycle process

software-defect-life-cycle-process

 

Also, during the test execution phase, the following participants are also involved who decide on defects from being logged to Defect Triage meetings.

 

  • Project Manager

  • Test Lead

  • Development Lead or Developer

  • Tester

  • Test Manager

  • Business Analyst

  • Environment Manager

The above entire team is called Triage Team. 

 

From the above flowchart, the flow of the Defect can be seen as:

1- At the initial stage a NEW DEFECT is being found by the Tester/defect owner and thus it is created with a NEW STATUS.

2- QA lead or Manager reviews the defect and assigns it to the development lead or manager with status as OPEN if he finds the defect valid. If not, he sends it back to the defect owner to recheck the defect.

3- The Development Manager/Lead will look over the defect and marks it as assigned. If the defect is valid, development lead passes it to the concerned developer. In case if the defect found is invalid, lead can mark it as rejected and sends it back to the QA team with a valid remark.

The Tester can further reopen or close the defect.

4-The Development team can also mark it as Not Reproducible if the defect is not getting reproduced from the description and steps provided by the Tester. In this case, the Tester will add more details of the bug and sends it back to the development team with caption marks as assigned. If Tester is also not able to reproduce the bug, it will be marked as closed.

5-The development manager/lead can mark the defect as duplicate if the Tester has already raised a similar defect. The Tester can close the defect if it is a duplicate or can reopen it, with a detailed explanation of the defect not being duplicate.

6-The developer will fix the bug and mark it resolved and pass it to the QA team to retest with status as resolved/fixed.

7-The Tester will retest the bug and will mark it as closed if it has been fixed or reopen the defect if it not fixed.

8-Last but not the least, the Development Manager/Lead can also Defer the defect, based on its severity and priority, with proper remarks with the defect. Also, the Development Manager/Lead can mark the defect as Won't fix, if the fix is not crucial or if the fix will cause other functionalities to break.

 

Defect Triage

 

defect-triage-team-gkmit

 

Resolution of defects is assigned, evaluated and prioritized by team triage as it's their only aim. The severity of the defect needs to get validated by the team, changes are made as per the needs, the resolution of the defect needs to finalize, and assign resources are assigned as per usability in agile project management.

 

Here through these questions let me give rest to your queries and study Defects can bring more business.

 

Problems and Solutions and bringing new Business:

  1. When to fix the Defect?

During Bug Triage, defects priorities are decided and based on them, the triage team decides as to when to fix the defect. If the Defect is least important, It is deferred, and Using Domain knowledge, Client could be provided with better solutions, thus targeting more business.

 

  1. Is it Worth to fix the defect?

At times, conditions arise when the defect fixing can cause more defects to emerge, also being a defect of low priority, then the team can decide to fix the bug later. Again saving time and cost, Again here, Management can look for Domain experts to provide more efficient business solutions.

 

  1.  When there is a conflict between Dev and QA team/Defect owner?

It is ubiquitous for having different views for a Dev team or a QA team on a defect/suggestion. Here comes the role of management, to give the best solution to the team adhering to the Business logic.

 

My view-

The business grows with value additions, the management can view the suggestions as a possible way to influence the client for a better solution, and this can bring more business.

 

Value additions are what keeps the client interested in an organization. Thus, the management can use the defect life cycle and defects to add more values to the work procedure.

 

I.e., due to ambiguous or incomplete requirements, there can be more valid defects in a particular module/block. Based on Domain knowledge, market trends, the management can suggest better solutions to the client, can influence the client by an accurate vision and check system and can generate more business.