I consider myself lucky to have the fortunates to work with many great project managers.  But at the same time, I also have the ill fortune to work with many not-so-good-ones.  One of the traits which I notice between those two groups are how much they really think about quality process.  PMs from the first group many times would want to know how testing is being planned and conducted, what test scenarios are being considered and executed.  Many times, they themselves would come up with end-user scenarios (aka "Use Cases") -- how the user would use their product in each and every scenario, step-by-step.  I truly salute these types of PMs since they are not only customer focus, but at the same time quality-driven.  They make testing easy and enjoyable.  Whenever I'm working on projects with these types of PMs, I always give extra 110% effort trying as hard as I can to find every little obscure bugs ensuring top notch quality because I just want the product to be great for their sake.  They deserve it.

Utilizing what I learnt and saw, here's my wishlist for a good and considerate PM:

1. A clear and precise requirement doc or spec which illustrate business justification, usage, and how would a feature look like.  Screenshots or mockups of new design are ALWAYS appreciated.  Remember that a picture is worth a thousand words (and it may also means less bugs).  Mockups are also a great for running pre-empt usability testing as well.
2. Think about the end-users on how THEY are going to use the product, not how YOU are going to use it.  Write down each scenario and go over them with us testers.  This will help us to come up with even more realistic test cases which are more likely to exercise the code.
3. Concrete and realistic milestones and timeline.  And please, please, please get input from both dev and test on how much time is required for our tasks.  Don't randomly throw darts at wall calendar and use those dates as milestones. 
4. Hold a spec review to make sure that everyone working on the project clearly understand your requirements. 
5. Make sure you clearly understand the test plan -- how to the test will be conduct, what type of test will be executed, who's assigned on the project, and what's the entrance/exit criteria defined by the tester.
6. Tester advice during bug meeting can be crucial and many times can reveal much deeper problem, so please pay attention.
7. Assume that the product is not going to be released until it meets the quality bar as identified by the test team.  Believe it or not, I had to endured a few PMs who were confident that their features would be released on a particular date (which they set) even though there were several showstopper bugs found a few days prior to that date.
8. Always have backup plan in case things didn't go the way you want it.  Either cut some functionalities, identify associated risks and how to manage it (if you do decide to release after all), or completely delay.  Although higher management may not like it, your end-users will thank you for it.
9. Relax and enjoy the ride.  Remember that everybody (the devs, partner PMs, test, support, etc.) are part of the same team.  The end result, regardless whether it's good or bad, belongs to everyone.  Keep this in mind as you steer the project through its cycle.
10. Hold a fair and thorough postmortem (if you decide to do it).  Past experience is the greatest teacher anyone can have.  If the project went well, learn from its success.  If the project tank, learn from its mistakes. 

As always, this list is simply what's on my head right now.  Feel free to comment or argue.  It's the learning that is important.