A tester's nightmare: wrong testdata

Imagine the following situation:
A team of IT-professionals are working hard to get a GO for a release of a module of their online CRM software. The architect designed the module, the developer creates the module and last, but not least, the tester has to do an end-to-end test to see if the whole chain is still working after the module is incorporated into the software.
As always, the end-to-end test is the finishing test, so the tester is on the critical path of the project. Better said, he has only 2 days to test and give a sound test advise of whether a GO/NO GO should be given.
Naturally, the tester prepared this test from the beginning.
While executing the testcases something weird happens: data is not migrated from the miodule to the other parts of the SaaS-landscape.
Awkward, because with other testcases this does not appear.

The tester thinks it's a bug, because the only difference with other testcases is the situation it wants to test and the expected result does not occur, so hee, it must be a bug. It's almost D-day and the tester has to go further with testing.
So, the tester documents the bug and communicates it to the team so the developer can pick it up and the tester continues the testing. Luckily it was not a showstopper.
The next day (the last day of testing!!) the developer comes to the tester and says it's not a bug, it's wrong testdata, which the database could not process.
After testing with the correct testdata the expected situation occurred. Shoot, almost a day lost due to bad testdata.

What can we learn from this?

A lot of you would say the tester screwed up here,he's responsible, but is he?
No!

In the beginning of the story I described the project and its team.
And that's exactly where the responsibility lies, the team!

This Single Point of Failure (wrong testdata) would not have occurred if other teammembers would have reviewed the testcases and the used testdata.
Then the rotten apple in the testdata would have been removed early in the process, even before the testing started.

A tester reviews documents and tests software for a living, but we are also human beings and we too make mistakes.
I am now a tester for 8 years and every now and then I use bad testdata.
But I learned to get my testcases reviewed and diminish the risk of using bad testdata,stall the test process and unintentionally get the project in the danger zone.

Bottom line, when you are testing in a very short time period, make sure the whole team is aware of the importance of testing and let them review your testcases, so the described situation above does not occur.