We ran into the exact same issue here when the TeamPulse development team switched from estimating in days to story points.
We addressed this issue by asking each team to look at a ordered list of stories that had been assigned story points and then estimate how many of those items they felt they could complete in two weeks (which was our iteration length). Both teams felt that they could complete stories that totalled up to ~21 points.
That's the number that we based our capacity range on. Over the next few iteration's, we discovered that the team's velocity ended up being in the 20 to 30 range, so we weren't that far off.
I encourage you to include testing effort in your estimates. That's what we do here and it's generally a good practice.
For each story that we have, we include at least one testing task and that task has hours associated with it.
The story point estimate that the team gives for a story should include the testing effort, which means that you need to include people who understand testing when you're assigning estimates to stories.
The larger issue you seem to have is that you don't have any predictability for access to testers. correct? If that's the case, then it's going to be difficult for you to have any planning accuracy. If the items that you're working on need to be tested before it's considered to be completed, and the people responsible for testing your work aren't available with any predictability, then planning with any level of accuracy is going to be difficult.
I'm not sure any tool is going to be able to help you with that.
Agile planning can be a little bit of a challenge, but there are great benefits once you get the hang of it.
This book helped me a lot. Agile Estimating and Planning
Our own VP, Joel Semeniuk, gave a talk at TechEd on this topic as well. http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/AAP309
TeamPulse Product Owner