The Lifecycle of a Salesforce Defect: A Case Study

The theoretical underpinning of defect lifecycles is rooted in the literature of software testing and quality assurance. The defect lifecycle (or bug life cycle) describes the systematic process a software defect goes through from its discovery to its final resolution and closure. Defects are a deviation from normal behavior, and there needs to be a repeatable process across the team and across sprints to resolve the defective behavior. A process to categorize and resolve defects is necessary, along with a template for defect reports. With that in mind, let’s look at a case study of a company’s Salesforce defect.

Case Study

At Company A, the client used Salesforce to manage their customers and vendors. A defect was found in one area of the customer management solution related to impromptu or scheduled visits. The defect involved the Impromptu Visits feature not being enabled. The defect was logged in DigTrans (a defect tracking tool used in Salesforce) detailing the title, description of the problem, steps to repeat, screenshots, and the expected behavior.

Title: Impromptu Visit Feature Is Not Enabled.

Description of the Problem: In the application, the Impromptu Visit feature is not turned on and needs to be so that further testing can be done with visits.

Steps to Repeat:

1. Login to the Salesforce application as one of the customers.
2. Navigate to the Visits part of the application.
3. Notice that the Impromptu visit button is grayed out, i.e., not enabled.
4. Notice that no further action can be taken to schedule a visit with the Impromptu button grayed out.

Expected Behavior: The Impromptu Visit feature should be enabled so that complete testing of the Visits solution will be provided to the client.

In Salesforce, the lifecycle of a defect, or bug, follows a structured process to ensure efficient resolution and maintain software quality. This process typically involves stages like New, Assigned, Open, Fixed, Retest, Verified, and Closed, with variations like Deferred or Rejected depending on the defect's nature. 

Below is a more detailed breakdown of the stages:

1. New: When a tester identifies a defect, it's initially logged as "New" in the bug tracking system.
2. Assigned: The defect is then assigned to a developer or a specific team for investigation and resolution.
3. Open: The assigned team begins actively working on the defect, trying to understand the root cause and develop a solution.
4. Fixed: Once the developer resolves the issue, the defect is marked as "Fixed" and sent back to the testing team for verification.
5. Retest: The testing team retests the fix to ensure that it has addressed the defect and doesn't introduce any new issues.
6. Verified: If the retest is successful, the defect is marked as "Verified".
7. Closed: Finally, if the defect is verified and no further action is needed, it's marked as "Closed," indicating the issue has been resolved.

Other possible statuses include:

• Deferred: If the defect is deemed low priority or its resolution can be postponed to a later release, it's marked as "Deferred".
• Rejected: If the defect is found to be invalid (e.g., due to incorrect information or a misunderstanding of requirements), it may be rejected.
• Reopened: If the retest fails or a similar issue is reported after closing, the defect may be reopened and assigned back to the development team.
• Duplicate: If the same defect is reported multiple times, it may be marked as "Duplicate" and linked to the original defect report.

At Company A, the implementation process followed a different path. When the bug was first discovered, it went into the New status and was put into DigTrans for the current 2-week sprint. 

Then, through discussion with the Product Owner (PO), the decision was to put it into the backlog for a later sprint. So, the bug went into a deferred status. When the sprint came up that included the defect, it was discussed during sprint planning. It was marked suitable for that later sprint, and then after much discussion, a priority and severity were assigned.

Then, it was story pointed. A story point refers to the number of days to code a solution to a ticket. So, for example, 1 story point means roughly 1 day to code a solution. Afterwards, a developer was assigned to it, and then an SQA resource. The bug was then moved into a fixed category and then retested, verified, and closed. This defect did not get tested in User Acceptance Testing (UAT).

The team found that this defect flow worked better for the product we were revamping. We had buy-in from the product owner every step of the way. Buy-in from the PO is the quintessential task that has to be completed. Once you have the buy-in, then you can feel comfortable that you are doing what is in the best interest of the client.

As you can see, the regular flow would have been for the defect to go from new to fixed to retested, verified, and closed. However, the defect went through new to deferred to fixed, retested, verified, and then closed statuses.

The software product we were working on needed the ability to create impromptu visits from the beginning. If this had not been provided when the solution was to be rolled out, it would have led to a missing piece of functionality and would have been costly for the client. Not to mention, this key piece of business would have been ignored. One caveat is that we did not have time to calculate the cost of ignoring this functionality.

Lessons Learned

The following is a list of the lessons learned from the case study:

• Catch defects early in the Salesforce lifecycle because the costs of fixing the defect rise as you proceed later in the development lifecycle.
• Sometimes it is necessary to work on a defect ticket in a later sprint. In this situation, it is important to get consent from the product owner.
• Begin the testing process as early as you can in the lifecycle.
• Be ready to change and adapt.
• Make sure you have a good defect tracking tool.