Found the bug status codes used by Oracle:
http://www.oracle.com/us/corporate/acquisitions/hyperion/bugstatusdescription-072226.pdf
I think that it is a sophisticated system and represents accumulated knowledge over time at Oracle.
Here are the processes I followed to use this system.
1. Unassigned Bugs
Bugs are typically filed with status 11, without an assignee
We call these unassigned bugs.
Unassigned bugs are in the triage person's queue.
These bugs will be prescreened. It may be assigned to an engineer, or may be pushed back as status 30.
2. Bugs under authoring
If the filer has not yet finished the bug logging process, he can keep the bug with status 10.
Those bugs are still in filers' queue and no one from development will look at those.
3. Bugs in Engineering's queue
The status 11 bugs are then assigned to an engineer to analyze the bug or to fix.
Sometime, we just redirect to the responsible person by the component
4. Need more Info or Clarification from the Filter
If we need more information from the filer, we set the bug to status 30
It is in the filer's queue.
If a bug is logged by customer support for a customer issue, the support team is responsible for updating the bug.
For development team, the bugs with status 30 may be ignored. We do not pay much attention to status 30. In some cases, especially customer bugs, we do proactively update the bug to ask people to update it, but we do not change the status.
5. Not Enough in the Bug
If the required information is still missing, we close the bug as 33.
The bugs with the status 33 are definitely ignored.
It can be officially closed as 93 permanently.
6. Reproducing the Bug
When an engineer is assigned to a bug from status 11, he or she may try to reproduce them. I have seen some other companies started using QA for this type of tasks. I feel that it is a good idea and won't waste valuable time from the engineering team, but it is not typically followed at Oracle.
If the bug is not reproducible, we set the status to 31.
All the status 30-36 are the pending status, it means that the development team feels that it is not a bug and would like the filer to verify.
7. Duplicate Bug
The bug triage person or the assigned engineer may set the bug to 36 if another bug is already filed earlier for the same issue.
Again, the 36 status is not the destination status. It requires the verification and confirmation with the filer. If the filer agrees that it is a duplicate, we close them as 96.
Typically we do not "reopen" a 9x bug. The status 90 to 99 are the destination statuses.
8. Fixed Bug
After the engineers fix the bug by checking the codes to the source control, the bug can be assigned to status 80 or status 37 depending on whether the QA is waiting for the build.
In some cases, the QA has to wait for the build available before the QA engineer can take the build, apply the build into the QA env and test it.
Status 37 gives the buffer zone.
Status 80 is definitely in QA's queue.
9. Status 19, 20, 21, 22, 23, 94, 97, 98 are for enhancement requests
Oracle bugdb is used for tracking the enhancement requests as well.
The bug templates are being used to collect different information for tracking enhancements.
http://www.oracle.com/us/corporate/acquisitions/hyperion/bugstatusdescription-072226.pdf
I think that it is a sophisticated system and represents accumulated knowledge over time at Oracle.
Here are the processes I followed to use this system.
1. Unassigned Bugs
Bugs are typically filed with status 11, without an assignee
We call these unassigned bugs.
Unassigned bugs are in the triage person's queue.
These bugs will be prescreened. It may be assigned to an engineer, or may be pushed back as status 30.
2. Bugs under authoring
If the filer has not yet finished the bug logging process, he can keep the bug with status 10.
Those bugs are still in filers' queue and no one from development will look at those.
3. Bugs in Engineering's queue
The status 11 bugs are then assigned to an engineer to analyze the bug or to fix.
Sometime, we just redirect to the responsible person by the component
4. Need more Info or Clarification from the Filter
If we need more information from the filer, we set the bug to status 30
It is in the filer's queue.
If a bug is logged by customer support for a customer issue, the support team is responsible for updating the bug.
For development team, the bugs with status 30 may be ignored. We do not pay much attention to status 30. In some cases, especially customer bugs, we do proactively update the bug to ask people to update it, but we do not change the status.
5. Not Enough in the Bug
If the required information is still missing, we close the bug as 33.
The bugs with the status 33 are definitely ignored.
It can be officially closed as 93 permanently.
6. Reproducing the Bug
When an engineer is assigned to a bug from status 11, he or she may try to reproduce them. I have seen some other companies started using QA for this type of tasks. I feel that it is a good idea and won't waste valuable time from the engineering team, but it is not typically followed at Oracle.
If the bug is not reproducible, we set the status to 31.
All the status 30-36 are the pending status, it means that the development team feels that it is not a bug and would like the filer to verify.
7. Duplicate Bug
The bug triage person or the assigned engineer may set the bug to 36 if another bug is already filed earlier for the same issue.
Again, the 36 status is not the destination status. It requires the verification and confirmation with the filer. If the filer agrees that it is a duplicate, we close them as 96.
Typically we do not "reopen" a 9x bug. The status 90 to 99 are the destination statuses.
8. Fixed Bug
After the engineers fix the bug by checking the codes to the source control, the bug can be assigned to status 80 or status 37 depending on whether the QA is waiting for the build.
In some cases, the QA has to wait for the build available before the QA engineer can take the build, apply the build into the QA env and test it.
Status 37 gives the buffer zone.
Status 80 is definitely in QA's queue.
9. Status 19, 20, 21, 22, 23, 94, 97, 98 are for enhancement requests
Oracle bugdb is used for tracking the enhancement requests as well.
The bug templates are being used to collect different information for tracking enhancements.
No comments:
Post a Comment