Anyone who says being a software tester is boring does not understand what it actually entails. Yes, there are times of tedium when you need to spend time with documentation, writing up test plans and test cases, etc.
But those are just the preparations for the journey. Like doing all the research and prep work for climbing Mt. Everest. You have to do all that tedious stuff so you can go do the exciting stuff.
And it is exciting! I love finding bugs in software. It's a hunt, a safari. You dive into the depths of the code and search for that elusive creature, the bug, checking each hiding place. And when you find one, oh the thrill! "Hey, look what I found!". Of course, the developers sometimes don't appreciate that enthusiasm, but it is fun! Like going deep sea fishing... hours of sitting and waiting, trying to lure the fish to your line... and that excitement when you finally have that massive marlin landed on the deck of your boat.
As I mentioned in a previous comment, I think it takes a special sort of person to be a GOOD software testers. You have to love the hunt, the search. Think Sherlock Holmes. He gets BORED when there's not a challenging case. To be a tester, you have to LOVE that challenge of digging into a new piece of code.
THis is what makes me laugh, not because of something funny, but because of the sheer joy of trapping that elusive bit of code that is causing trouble and being able to describe it to the developers. I laugh out loud when, after hours of testing, I FINALLY caught one.
As for unusual bugs, I think the one that gave me the greatest joy was the one that got me the reaction from the developer of "It works on my machine". I could demonstrate it, at will, on my own box every time. I even had the developer sit down at my desk and follow the steps and reproduce it... but yet it still worked on his machine.
So, we sat down at his desk, the IDE open in front of us, and stepped through the code. And sure enough, it worked on his machine. We spent hours at it, trying to figure out what was different. Then we saw it. An uninitialized boolean variable. In the IDE, that variable was being given a value of "true" and so everything worked properly. However, that only happened when running the code via the IDE. When he compiled the code and ran it outside of the IDE... sure enough, it broke on his machine. This was a particular problem with that IDE that uninitialized booleans would be defaulted to true so, if your code didn't eplicitly set the value before using the variable in a logical expression, it would always pass. Lesson learned.