A spec that can’t be tested is a starting pistol in a treasure hunt. The treasure is information, but not any old bit of information – you, as a tester, must get the same information that was given to the programmers.
Because what makes a spec untestable? The fact that it doesn’t explain anything. There are no work-flows, no parameters, no boundaries, no states. There are entities so poorly defined that they’re nearly indistinguishable, vague goals instead of clear actions, buzzwords and sales-speak instead of page breakdowns. So what do the programmers do, faced with a spec that might as well be a blank page? They gather their own information, they guess, they improvise – all without writing down a single word. All things that testers can do, too. But if all this gathering and guessing and improvising is not done together, the results will be different; they’ll programme one thing, you’ll test another, and the spec writer will have the gall to complain about the outcome.
So you and the programmers must form a team: find the information together, or pass it to each other, and always document it. You all have to know what the spec was supposed to say, put it within the boundaries of technology and common sense, and then determine what the spec actually says. That’s what they programme, that’s what you test.