The primary thing is to try really hard to find bugs.  This may sound obvious but in fact often QA folks are intimidated by software developers and in addition many organizations reflect this in their workflow and processes.  It is easy for a QA person to think, well if I PASS this and the developer can move on I will make them happy.  While that might be true of inexperienced junior developers, a mature professional developer will actually be very happy for a tester to find relevant bugs that they missed and over time trust can grow.

In addition:

- Test the edge cases that developers often don't look at
- Test on a wide variety of devices, browsers and versions that the developer may not have tried
- Test sad paths the developer may not have tried
- Ask to pair on test plans up front
- Share testing tools with the developers that will use them
- Work in the same physical area
- Respect working habits, 'flow' and learn how/when to interrupt and when not to **for each dev**
- Share a common wiki that documents setup knowledge
- Work on making sure environments are the same so that bugs found are not just due to environment differences
- Use a "three amigos" (http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/) approach to help bring QE, product and dev together to work collaboratively
- Clearly document the steps to reproduce bugs that are reported and include: exact URL, data used, steps to follow, options to choose, etc.
- Pair with a dev when experiencing / recording a bug.  They will frequently ask "show me the console" or "show me the network requests" or "show me the database record for that", etc. This can be helpful not only in fixing it but also in ascertaining the initial priority and importance and whether it should even be worked on.
- Use screenshots and desktop movies when recording bugs.
- Learn the business domain as much as possible so that assessment, prioritization and description of bugs is related to business needs.
- Study the skills behind good QE and be an advocate of them to developers with presentations, emails, adhoc conversations, etc.