How to respond to requests to retest, in hope that the bug is gone?
We sometimes get requests from developers to re-run a failing test on the latest build, since "we did a lot of changes" and they hope the bug is gone.
On one hand, one can claim that they should know what they are doing and not hope that some side-effect removed a bug. It also projects lack of respect for our time, if they can run the test easily on their system. On the other hand, if they did do a lot of changes, then it's actually possible they fixed the bug.
What should be the response?
While at it: if the bug is indeed gone, how should it be closed? (we use: "Rejected" with a Reason field = "no longer seen").
Any other approaches?
As a developer, not a QAist, I have a responsibility to provide software that meets the specs, with as few errors as possible. From my perspective, QA has the responsibility to inform me of any errors that I have made. I place them in extremely high regard for that.
When QA tells me that "they found a bug" they found that bug in a particular commit. The code was different before that commit, and the code is different now. Often, bugs are found in developed features, which will change considerably within just a few commits. It is very, very likely that the code they tested against last week has changed, even if just the line number for error messages has changed.
When we ask you to retest, it is not because we value your time less than ours. It is because the code no longer exists in that file line, or that file, or it is no longer coupled to that class, or the business requirement have made that feature obsolete, or the Python version was updated, or a million other things. Code under development is dynamic, and any bug filed against a specific slice of the development process is likely outdated after just a few more slices to that part of the application.