When things go wrong, it is very common for various people to attempt to blame the other team members for project failures. Sometimes it's the Business Analyst for coming up with bad requirements, or the project manager for not allowing enough time in the schedule, or the testers for failing to handle all the right edge cases, or the client for not knowing what they actually want, or management for not clearing the obstacles, or even the developers for writing crap code, etc.
A manager in this situation may not know exactly where the blame truly lies. Especially if the manager is less technical. For all you know maybe "Bob" has been talking to "Charlene" about the problems he's run into trying to test what was delivered to him. Maybe "Charlene" even told him to approve things in order to meet the delivery dates because of pressure she's received from her boss. Maybe one of the other developers has said that you were the problem.
I'm not saying any of this happened, but the point is that there is likely more going on that you don't know about.
Because of this, you should never throw a specific person under the bus to your boss' boss. It would only look incredibly bad for you.
Now, to the direct questions you asked:
Should I have told Dave that I think Bob should be fired?
Should I tell Dave this now? Work has not yet started on this next project, maybe something could still be done?
Absolutely not. Ultimately this project is under "Charlene"s direction and she is obviously well aware of your concerns. Any failure here is ultimately her failure. It is not your job to attempt to undermine her with her boss.
Unless, of course, you are trying to get her fired in some attempt at taking over her job. If that's the goal, tread carefully.
Was it appropriate not share my to disagree with Charlene in front of Dave?
Yes it was appropriate to NOT share your thoughts about "Bob" other than in generic terms. Getting specific would really just turn out badly for you.
Now, I'm going to add one more thing. I've held every IT job from entry level tech support through CTO and I've probably seen every way a project and team falls apart.
The true Rockstars(tm) on my various teams were not the people coming into my office telling me to fire someone. The Rockstars were the ones who sat down and helped the ones failing. If you want to be a MVP then go sit down with "Bob" and train him on how to do his job. Show him what to look for, how to set up test plans, how to record his results, how to write bug reports, etc. This isn't going to be a one hour thing. Rather we're talking about spending an hour a day with this guy for a couple months.
In short, rather than trying to push him out, help him stand on his own. You'll earn not just his respect but the respect of management and, hopefully, help to ensure the success of the project.