Recently, we had the classic debate whether when discovering an (unrelated) problem, a bug fix:
- should be rejected/marked as failed,
- or if you pass it, but log a new bug.
Sam said he had never logged a new bug if testing failed, even if this issue wasn’t called out in the bug report; in the description or recreation steps.
So to explain using this situation: I had fixed the Entity Framework code which saved a new row to the database table. The bug was for passing correct values into it, and my change was fine; the correct values were now saved in the appropriate columns in the new row. However, if you send multiple calls at once, Sam noticed it wasn’t incrementing the number by 2 as expected, only by 1 (the first call was then essentially being overwritten – a classic concurrency problem).
I think it’s reasonable to use the original Work Item (Bug Report) to flag any issues testers find, but once we confirm the new issue isn’t caused by my change it should go into its own Work Item. You might assess that the new bug could be fixed in a later release. It makes no sense to fail bug A because you found bug B.
Sam is basically increasing scope, then moaning that we might fail the sprint, because we cannot complete the new item within the 2 week deadline.
Stranger Coding Tings 