Closed
Bug 365961
Opened 19 years ago
Closed 19 years ago
Bugzilla Problem: Bug Fixed, but not in a QA build
Categories
(Bugzilla :: Bugzilla-General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: alowenstein, Unassigned)
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)
Build Identifier: Bugzilla Version 2.22.1
====> PROBLEM DESCRIPITON
I have, what I believe to be, a very generic issue. Here is the proper use of Bugzilla as I understand it.
1. When a developer is finished fixing a bug,
a. the resolution is changed to FIXED
b. the status is changed to RESOLVED
2. When QA approves a bug, the status is changed to VERIFIED.
However, there a time lag between
o when a developer fixes a bug and
o when a build with the bug fix is available to QA to verify the fix.
Thus, a bug may be fixed (at least in a developer's view), but can not be tested by QA.
Moreover, there is a second time lag between
o when a bug is VERIFIED by QA and
o when an organization/company releases a version with the bug to its customers
Thus, a bug may be fixed (at least in a company's view), but is not available to the company's customers.
I don't know how to use Bugzilla to address this issue. If there is a way, I will be happy to use it. If not, here is a proposed solution.
====> PROPOSED SOLUTION
I propose that this issue could be solved if:
o A developer had to enter a version number when a bug is update to FIXED.
o QA had to enter a version number when a bug is update to VERIFIED.
Here's how that would work. In item "PROBLEM DESCRIPITON 1.", a developer has fixed the bug, however, development often will not have a build that is suitable for QA. This may be beacuase:
o Development hasn't gotten around to doing a build with the fix
o Other items have been worked, and a build may be unstable due to other on-going development work
o others???
In any case, it is important for QA to know when to test. One way that this could be done is as follows. The developer enters (should be forced to enter??) the version in which the fix is available. Here's an example of how that would work.
o Assume that version 4.34.92 had a problem
o Assume that developer fixed the problem after a build of 4.36.104
o At the same time the developer updates the Bug to FIXED, the developer would indicate that the bug has been fixed in 4.36.105 (i.e., any build after 4.36.104)
o Subsequently, a build is released to QA. If the build number was 4.36.97 (i.e., less than 4.36.105), QA would know that bug IS NOT ready to be tested.
o However, if the build number was 4.36.110 or 4.40.34 (i.e., greater than 4.36.105), QA would know that bug IS ready to be tested.
o So when QA receives a new build, QA could, if there where a FixedInVersionField, search for all bugs where "Resolution=Fixed", "Status=Resolved", and "FixedInVersionField >= NewQaVersion". (I leave it to the Bugzilla developers to determine the best way to enter/store/compare version numbers.)
Similarly, if QA validates a bug fix, users may or may not be able to get a version with the fix. Thus, when QA marks a bug VERIFIED, QA should enter (should be forced to enter??) the version in which the fix is available. That way a user can compare the latest available version against the version in which the bug was VERIFIED, and thereby determine whether the bug fix is available.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
![]() |
||
Comment 1•19 years ago
|
||
That's what the target milestone is for.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•