Q:

How to prevent overwriting changes in TFS version control by another team member

Background:
I'm asking this question as a UI test engineer.
We have a small software team using TFVC on a TFS repository.
We use the mantis bug tracking system to follow up on issues.
Here's the situation:
While manually testing a program, I found a bug and reported it to the devs.
A few days later, a dev has let me know the issue was resolved.
Some other day, I started testing to see if the bug was resolved but found the exact same bug.
problem:
Someone made a change in the code in order to fix the bug.
A few days later, the code got changed again, reintroducing the bug into the program. I don't know if this occurred because of the auto-merge feature in TFVC or that the change was made by another programmer who did not know about that fix.
question:
Are there ways to prevent such errors from ever happening? Or is this just sloppy work from that dev who changed the code back to its original form?

A:

There are two techniques that work together to avoid this type of scenario from occurring:
Step 1: write a failing test before fixing the bug
When the bug has been found, the first thing to do is to write a test that will pass when the bug is fixed and thus it fails whilst the bug still exists. The dev then fixes the bug and in the process makes the test pass.
That way, when the second dev undoes the fix, a test will fail, alerting them to the fact that they are (re)introducing a bug.
Step 2: use pull requests
Rather than committing changes directly to TFS, use pull requests instead. That way, each change is checked by someone other than the developer making the change. This effectively ensures all changes are code reviewed. That not only guards against issues such as described in this question, but provides the many other benefits around code quality associated with code reviews. 

