Edit

I want to be clear that this answer is only talking about the concept of testing your QA process, and I'm not defending the specific methodology portrayed in the question.

End Edit

There is a valid reason to check if your testing/checking is actually working. Let me give you an example from manufacturing, but the principle is the same.

It's typical when feeding material through a machine that the feeder might not push the material through far enough. This is called a "short feed" and to prevent this we might install a "short feed sensor" (typically a through-beam type sensor that's blocked by the material). This sensor detects the end of the material when it reaches the full feed length. At a certain point in the machine cycle we check that the sensor is blocked, and stop the machine if the check fails.

Now you have to think about how the test itself can fail. For instance, some dirt or other debris can block the sensor and it will always report "OK" and never stop the machine. Also, the nature of the sensor is that the receiver turns on when the beam hits it, so depending on the type of sensor you have installed, electrically you get an "ON" input when the sensor is not blocked. That means if the cable got cut or power was lost to that sensor, or the input failed, the logic of your program would read "OFF" and that would mean "blocked" or "OK".

To catch these failure modes of the test, we typically insert a second check to make sure the sensor is actually unblocked during a second part of the cycle. In this way we check that the test is actually still operating (as best we can).

Similarly there are many ways that a QA department can fail. Perhaps the automated tests didn't run and the report is looking at an old copy of the test data. Perhaps someone isn't doing their job right. Testing the QA department is a reasonable thing to do.

Obviously the draw-back is that a "test bug" could make it through the QA department and into the finished product. In the manufacturing industry there are sometimes cases where a known bad part, sometimes called a "Red Rabbit", is inserted into the process (typically by someone from QA) and they watch that part go through the process and measure how long it takes to find the part and remove it. Normally this part is painted bright red (or orange) so it can easily be tracked. Since someone is watching the part go through process during this test, the chance of it making it into the final product is practically nil. There are, of course, apocryphal stories of someone throwing a known bad part into the process to "see if the system can find it", and of course having to quarantine all the final parts produced that day and manually sorting them, but that's just a case of not performing your test with due diligence.