The job of a tester is to put together a meaningful plan - understand how the software is going to correspond to the business needs and test the main logical paths as well as some optional and failure paths and find out what the software really does as opposed to what people think it should do.
Yeah. What he said. Sure, misconceptions abound, but when the role really is "software test engineer", the job is a lot more important than just running scripts and trying to make the software break. I think this may vary vastly between employers, and in some (or most?) situations the management themselves probably don't understand what they should be asking for from their testers. The reality is destructive testing only covers a portion of the job, while to do the job well a lot of knowledge and imagination can be needed to grasp the entire scope and complexity of the software, knowing what goes on in the back-end data, what the users see and believe is going on with the particular parts of the s/w that they use, how action in one person's role effects what is seen by a user in another role - the tester needs to see the entire view which individual users may never be involved in.
I have great respect for the testers I work with (not least because they can handle a grumpy developer without hitting me) and often prefer to go to the tester instead of the B/A for answers. Development environments may differ, but when I have a nasty bug to hunt down which requires data to be set up in multiple integrated software solutions to get just such an error to occur between them, I can't imagine what I would do without somebody there with the knowledge and patience to go thru the entire scenario to reach the point where he can say "now press that button and watch what happens".
Sure, its still annoying when the tester comes back and tells me that little Bobby Tables just broke my database, but yeah, they do need to do the simple basics first as well I guess.