|
|
At my company, the normal workflow dictates that no matter how low risk a hotfix is, we never release it to a customer without fully testing it first—which usually takes at least a full day or two for even the smallest changes. That's a sound process, and every company would do well to adopt something similar. But there was this one time when an obscure bug completely blocked a customer from running our product at all, and the customer desperately needed to run the program in order to get some stored data. Waiting 2 days for a full test cycle was not an option, so we agreed to give him the fix as soon as development finished it. After all, the customer couldn't even run the program at all—our fix could hardly make things worse, not even if we were deliberately trying!
Situations like this sometimes make it necessary to bypass the workflow. That shouldn't be done without the approval of the product leader, but appropriate conditions do sometimes arise. When they do, make sure that your tracking system has a mechanism for manually bypassing states of the workflow. You want the ability to manually set the workflow state. That way, when push comes to shove, the defect tracking system won't hold you down. Implementing the ability to manually set the state is very easy technically (just set one field in the database), but make sure your GUI supports it.
Remember bounce-back PRs? That's when a developer thinks she fixed the bug, but the tester discovers the bug is actually still occurring. Bounce-backs happen surprisingly often—I've seen highly competent teams still get bounce-back rates of up to 10 percent. Sometimes, the developer misunderstood the bug description. Other times, the tester misunderstood how the program is supposed to work. Or maybe the developer really did fix a bug with one set of input, but the same bug still occurs with a different set of input.
You can reduce the problem by testing your code more before submitting it to the testers. But you'll never get away from the bounce-back problem entirely. Part of your workflow should state that only the person who discovered the bug can permanently close it. Other people can recommend the bug be closed, but only when the person who discovered the bug is satisfied can you be completely sure that the issue really is handled.
Accounting for bounce-backs in a workflow is easy. After the developer fixes a bug, the PR should not transition to the "closed" state. Instead, it should transition to an "open for testing" state so the testers can confirm whether the fix works. Assume that in many cases, the fix will be rejected and the PR will transition back to the "open for development" state. Be sure to factor this into your schedule, or else you'll miss your ship date.
|
|