If your team writes specs before starting to code (as opposed to after, when it's easy to do so, and the spec is more commonly called documentation) you certainly have cause to be happy, but you aren't home free. Another bone of contention awaits: whether a particular bug is a code bug or a spec bug.
Sometimes a program will function correctly per the spec but that functionality will be determined to be incorrect. More often, the spec will be hazy about or outright omit details regarding a certain edge condition, unusual circumstance, or completely mainstream scenario. The developer may not see this omission as a big deal and so will decide on her own what should happen. If you're lucky, the developer chooses the same behavior as you (and your customer) expect. If not, you are in spec bug limbo.
Your best course of action at this point is to discuss this issue with your feature team (or, at the very least, your developer). As with most everything else in this industry, a little conversation often goes a long way, and a reasonable resolution is shortly reached. If the question turns out to cause massive controversy, well, at least y'all're talking it through, which is far better than the alternative: embarking on a Bug Bounce.
"Bug Bounce" is my term for a fight between team members that is carried out via the bug database. It usually goes something like this:
Not every disagreement between Dev and Test is due to a spec bug, of course. A statement that is completely clear to one person may be rife with ambiguity for another. Whether this is a spec bug is debatable. The effort required to make a spec completely unambiguous to all parties is rarely worth spending, so some amount of ongoing discussion is to be expected. Just remember it's all fun and games until someone gets their code poked out.
*** Comments, questions, feedback? Contact me at michhu at microsoft dot com.