In this hypothetical situation is it really it really be the fault of one engineer?
Most bugs are really, really stupid. Like forgetting a term in a boolean equation. But some of those take very arcane combinations to trigger. When they finally do on silicon, it can take days or weeks to find out what exactly when wrong. And then the fix is usually obvious.
So, yes, most of the time, it's possible to know exactly which designer made the mistake.
That said, unless there's a repeated pattern of the same guys screwing up time and again, I've never seen anybody fired or even reprimanded for a silicon bug and it can happen to the best of the best.
The problem is that there are a million of trivial things that have to be covered and a bullet proof guarantee that everything works is usually impossible or would double the schedule. These days, a major part of testing is done with directed randoms: you create random inputs that conform to the required protocol and you apply them at random cycles to the block under test, but you control the distribution of the inputs to guide the design into certain expected corner cases.
E.g. when verifying an ethernet switch, you'd create a test with 5% medium size packets and 95% very short packets. Another one test would do the opposite. Yet another test would make sure that packets at different ports are applied at roughly the same cycle to check memory conflict handling. etc. One chip can have tens of thousands different tests.
Anyway, once your random tests are implemented, you (automatically) kick them off each night or each weekend and see what comes out. Initially, bugs will trigger very quickly, but some don't. I've had it happen once that a block that was completed months earlier and that had been passing randoms tests successfully all the time trigger a bug just a few days before tape-out. That's just being very lucky that the 'right' combination was triggered.
But it might just as well only have triggered when the chip was already in the fab... or later.
