A poisoned message is a message leading to an error because of the message itself and not a database condition.
For instance, a message leading to a deadlock is not a poisoned message because it can complete with the next retry.
A message leading to a primary key violation will always fail, regardless of the number of retries (assuming there's no DELETE operation in between...).
To test such a scenario, find a message condition that'll pass your validation process (I hope, there's such a code section 😉 ) but will still fail, leading to a rollback of the code activated by the message.
Without knowing the tasks you trigger with a SSSB message it's hard to tell how to simulate a poisoned message...