|
|
Even though you might not formally document it or even be consciously aware of it, your development process follows a workflow. Your workflow is like an assembly line—one person must finish his part before the next person can begin to work. A developer can't fix the bug until a tester (or someone else) has found it, and the tester can't verify the fix until after the developer has coded it. A typical development workflow is shown in Figure 9-2, but this is by no means the only possible one. Some workflows might have additional steps, such as requiring a code review of each bug fix or creating an automated unit test. Your workflow might be an ad hoc system held together by informal consensus rather than official policy, but every organization has a workflow of some kind or other.
One of the problems with a workflow is that people often don't realize when the ball moves into their court. After you've fixed a bug, do you e-mail the testers to try the fix? If not, how do they know you're done? But if you do e-mail them for each bug you fix, then what happens if you either forget to e-mail or else they get e-mails about dozens of bugs on the same day? Then that bug may get overlooked, and 3 days later, everyone will be too involved with new bugs to remember the one that got away. Without someone or something driving the workflow, it's easy for a bug to fall out of view and disappear.
Sending a PR back to an earlier state in the workflow also often results in confusion. Many times, a developer will need additional information before she can proceed on a bug. She'll e-mail her questions to the tester, but if that e-mail gets lost in the pile with a hundred others, then several days may be unnecessarily wasted before someone notices no work is being done on the issue.
Another problem with workflows is that steps tend to be accidentally skipped. Suppose a customer reports a bug, a tech support rep creates a PR describing it, and a developer fixes it. The next step in the workflow is for a tester to verify the fix. But at lunch, the developer happens to mention his fix to the tech support rep, who incorrectly assumes that means the fix is now ready to be sent to the customer and doesn't realize it hasn't yet been tested. Then the customer gets a fix that may not even work in all cases. Miscommunications like this happen, and without some formal system to track the workflow, serious mistakes are nearly inevitable.
Defect tracking systems can enforce a workflow to eliminate these problems. Rather than counting on each individual to notify the appropriate person when a phase of the PR is completed, why not let the tracking system do it? The system assigns each PR a field called "State", which identifies who is responsible for the PR at the moment. Is the bug currently under investigation by development? Has it been returned to the tester for clarification? Based on the state field, you can tell where in the workflow this PR is. Generally, you don't manually set the state on a PR—that would risk accidentally setting it to the wrong state, thereby skipping over something important. Instead, each person usually just checks off a box that says "My part is done" and then the system automatically moves the PR to the next state.
In addition to a "state" field, each PR usually has an "owner" field that identifies the specific person in charge of the PR at the moment. Often, altering the state will change the owner automatically—for instance, as soon as the developer marks a PR as "open for testing", the owner of the PR will be switched to the tester.
| Note |
How does the system know which tester to automatically assign the PR to? One way is to define a transition in the workflow—any PR closed by developer Sue will go to tester Joe. But what if Joe is on vacation that week? Another way is for the system to load-balance by assigning the PR to whichever tester has the fewest PRs already. But what if a different tester has special expertise and would be a better choice? Alternatively, you can have someone manually assign the owner—as soon as the PR moves to the testing stage, all the testers see it until one person claims it as his own (or the leader assigns it). That's the system I prefer, although it has its drawbacks, too. |
The owner field is great because it lets an individual quickly see the issues he is responsible for. This reduces the risk of anyone forgetting about an issue. Even better, many tracking systems will notify you when new information comes in about an issue—most systems can be set to optionally e-mail you whenever a PR is newly assigned to you or one of your PRs is modified by another user. Another notification method is called unread marks. Ever notice how your e-mail inbox shows new messages highlighted until you read them so you can quickly tell which messages haven't yet been viewed? Some tracking systems can do the same thing, highlighting new or recently modified PRs. Either system works; just choose what you like better.
Even without notification methods like e-mail and unread marks, though, viewing the PRs you are responsible for is usually very easy. Just query the database for all the PRs that are assigned to you. Team leads can also do this to quickly see which team members are most overloaded and which are available for additional assignments.
|
|
