If your IV is predictable this is as (in)secure as assuming that you have a zero vector IV.
And a zero vector IV allows you to perform a so-called Adaptive Chosen Plaintext Attack (ACPA).
Assume that you have a encryption mechanism that works in CBC mode. This means, that on the first iteration the $IV$ is XORed with your input message (which is only the size of one block) and then encrypted. On the following iterations the output of the previously encrypted block is used instead of the $IV$.
If we can predict the $IV$ that is going to be used, then we can XOR our message $x$ with that $IV$ before putting it in the CBC-thing. The CBC-thing is then going to XOR our message with the same (guessed) $IV$ again.
$(x \oplus IV) \oplus IV = x$
With this knowledge we can deduce the behaviour of our CBC-mode encryption as if the IV was non-existant or a zero vector.
This is especially important or meaningful in a scenario where you only consider the final output of the CBC-mechanism to be important, which is the case of a CBC-MAC (a MAC constructed with a block cipher used in CBC mode).
If you are able to send a few test blocks to some MAC-function with predictable $IV$ and receive the response, you may be able to produce valid MACs for a specific message without knowing the key and without submitting this very message for authentication.
Note that MACs are usually only produced by the key owner for messages that he approves. If you can trick the key owner into authenticating a few apparently random blocks of data for you, his MACs are attackable.
Small example, where we assume, that the block size of the encryption function is five (5) characters long (for demo purposes):
Scenario: Let's assume that the key owner is willing to authenticate any bizarre data with his CBC-MAC for you, but under no circumstances would he want to authenticate the message "HelloWorld". The goal of the attack is thus to gain enough knowledge from the key owner to produce a MAC for the message "HelloWorld". Of course without stealing the key or slamming him with a ruber tube.
Here is how it could work:
1.) Correctly guess the $IV_1$. This somehow is optional, see below. It maybe makes understanding the attack easier, but usually a CBC-MAC will publish the used $IV$ together with the MAC, because both parameters are needed for verification later. An $IV$ thus only needs to be guessed beforehand if the attacker wants to neutralize the $IV$, which is what we will do in step 3.
2.) Send the string $s_1$ = "Hello" (XORed with the $IV_1$) to the CBC-MAC-function and receive or read the resulting encrypted data $y_1$, which is in this case also the MAC $m_1$ for $s_1$ in case the $IV$ is the zero vector or for $s_1 \oplus IV_1$. If neutralizing the $IV$ this resolves to the encryption of the single block $s_1$ without any $IV$.
$MAC(s_1 \oplus IV_1) = y_1 = m_1 = encrypt_K(s_1)$
$MAC(s_1) = y_1 = m_1 = encrypt_K(s_1 \oplus IV_1)$
3.) Guess the next $IV_2$. This really neutralizes the unwanted $IV$ and instead simulates a chaining from a previous block, which we actually don't have. => The core of the attack!
4.) Send the string $s_2$ = "World" XORed with the $IV_2$ and XORed with $m_1$ to the CBC-MAC-Function and receive the resulting data $y_2 = m_2$. XORing $s_2$ with $IV_2$ neutralizes the $IV$ of the CBC-mechanism and XORing that with $m_1$ simulates an cipher-block-chaining from the previous block "Hello".
$MAC(s_2 \oplus IV_2 \oplus m_1) = y_2 = m_2$
5.) The MAC for the Message "HelloWorld" is $m_2$ if the $IV$ is set to be the zero vector at verification time (because $m_1$ is the MAC for "Hello" with a neutralized $IV$). Alternatively, as described above, if one would find a zero vector $IV$ to be odd-looking one could just not XOR $s_1$ with $IV_1$ in step 1, and instead store $IV_1$ for later use in the verification step.
(remember: the block size is five characters, HelloWorld is thus two blocks.)
Since the IVs are sent along the MAC for verification the attacker constructed a valid MAC for the two concatenated blocks ("Hello", "World") without knowing the Key and without submitting this message ("HelloWorld") to the MAC function for authentication.
I hope I could provide you with a good example about the problem of a predictable $IV$ in the context of chosen plaintext attacks.
Update: on a side note, and to precisely answer your question: you can verify that the guessed $IV$ is correct by XORing a test block with the $IV$ and sending it to the CBC-mechanism. Then you repeat the operation again with another correctly guessed IV. If both resulting outputs are equal the guessed IVs were correct. If not either the first or the second or no $IV$ was correctly guessed.
It is important to understand, that especially in the case of CBC-MACs the $IV$ is not a static configuration, but a random value chosen by the mechanism on each invocation.