As a tester, have you ever had to ask whether your defect fix was deployed to a particular environment? You shouldn’t need to, because the answer should always be readily available. Having to request information on the status of your defect fix indicates inefficiencies and a lack of maturity within your organization’s software development process—an open invitation for delays, miscommunication, and mistakes.
A smarter solution is for the defect report itself to be a repository that holds all the answers, containing the defect’s deployed environment information and keeping in lockstep with its deployment journey. The defect report, which should be easily accessible through the defect tracking system, should indicate the defect’s status and the environments the fix has been deployed to, as well as whether it has been verified in each environment.
This type of reporting, which could be either automated or performed manually, eliminates the need for guesswork and hunting people down for answers.
Companies typically develop software utilizing separate sandboxes, with each having a specific purpose, such as the developer’s sandbox for coding, unit testing, and integration, and the tester’s sandbox for testing, defect verification, and other QA-related functions. Additional sandboxes are sometimes used for performance testing, user acceptance testing, and security testing. A defect fix travels through these sandboxes until it reaches its final destination of the production environment.
During a defect fix’s journey, it is customarily verified within the tester’s sandbox and then closed before reaching production. However, multiple defect fix verifications might be needed when an organization suffers from unreliable deployments, inexperienced developers, overly complicated software designs, or poor development practices. Consequently, verifying the fixed defect solely within the test sandbox might be insufficient, and it’s sometimes advisable to perform continuous testing of the defect as it makes its trip through the various environments.
In these cases, it’s especially important to know where your defect fix has been deployed at all times. To avoid confusion, the latest deployed environment should always be updated within the defect report. The report should also indicate whether the defect was tested and verified in each environment. This ensures that the defect won’t be closed until it’s been verified as fixed in its last environment before production.
The defect report should be the centralized location for all relevant information—a living document that singularly captures the defect’s evolution, encompassing its entire lifespan from initial discovery right up to the fix being released into production. Having a self-contained report detailing the events leading up to the defect’s ultimate closure allows you to rest assured that the defect was resolved properly throughout its entire journey.
A defect fix should be able to stand alone, independent from the need for any real-time verbal exchange between employees. You should be able to look at a defect ticket and know the complete story without any human intervention, so that at no time should you ever have to ask, “Do you know where my defect fix is?”
