0

The requirement is almost implemented with an exception of one single and simple but critical bug (the bug is like "constant X should be added to the final value"). As soon as there is a high priority of evaluation correctness the bug is crucial.

HP ALM has two fields for requirement status:

  • direct cover status (is about test runs, tests which cover this requirement)
  • status (is about the phase of requirement lifecycle)

Direct cover status is clear to be set as Failed.

The problem is Status. I can not leave status as In Testing cause we have already tested the requirement. And I can not say the requirement status is Not Implemented cause devs need to do just a simple fix. And it's strange to set the status as Implemented cause there is a crucial bug after implementation.

Which status should be set in this case? Why?

2

I'd consider this more of a process question than a tool-specific question: a requirement has a critical bug in the implementation.

My opinion is that the critical nature of the bug should mean that the requirement is consider not implemented until the bug has been fixed. At that point it returns to in testing while the correction is tested and the acceptance tests are re-done.

The reason for this is that with a critical bug, no matter how simple the fix is, the software can't be released.

| improve this answer | |
0

If requirement is tested, and fails, there are two possibilities:

  • Release it with a known bug, and create (and prioritize) the bug to be fixed in one of next releases.
  • If bug is so critical that product cannot be released, it goes back to development, and when fixed, it will have to be re-tested in full once again. You have no idea if fix did break some other functionality or not until you tested it. Simple bug fixes are known on occasion to break system in a very subtle way. Tester's work is never finished: we just test as many of use cases as we can in available time, and pray that the rest will not have any critical bug.

So status should be "in development", and we'll see you after you fixed it.

You cannot "prove" that software has no bugs: only check that subset of known bugs was fixed.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.