You have a client, on whose behalf you are building the next Twitter (or whatever). You're a nice, forward-thinking, modern software kind of guy, so you've agreed to take client feedback throughout the project and to put up interim builds frequently to show progress. In addition, you've got a tester who will work on this project as it gets built.
Do you let your client see your defect tracking system? The one your tester is using?
Let's think about this for a minute:
Pros of having the same defect tracking system for internal (your tester) and external (your customer) feedback:
- No more copying and pasting from emails or one system into another. You've just bought someone hours of time!
- Fewer duplicates. Your tester will confirm things your customer saw rather than double-reporting them, and (hopefully) vice versa.
- More comfort. Your customer knows exactly what he's getting and gets some comfort that you're not just writing and waiting on him, but that you're actually using this and working out the kinks before it goes live.
- All your warts? Totally visible. This is really the big downside here.
- You all have to watch your language a bit. No putting "the customer is always right, even if they're total idiots" in bugs.
- Less comfort. You mean you're not perfect? If the developers didn't catch this, then what are they missing?
Notice that customer comfort appears on both lists; both of them are probably in play a bit, and which one dominates will depend on your customer. Most or all of the customers I've worked with, though, have fallen into the more comfort camp. They know software in general has problems, and not finding them means you're not looking. And if the customer doesn't see you finding them, then as far as he's concerned, you're not providing that comfort.
My preference is to err on the side of transparency. I think that showing the client you're not hiding anything is part of building a good relationship. I also think that you shouldn't be denigrating your client even in private (you never know what might slip out into public!). At least for the team I often work with, knowing that the client is going to see everything also incentivizes the developer to poke at it a bit harder before putting it out for public review (not true of everyone, I'm sure, but having an incentive to not slack off never hurts!).
If you want to not share with your customer, ask yourself what you're hiding, and what would happen if your customer knew. And then go out and fix those things. The things you hide, those are your problem areas. Being transparent will make you fix them.
There are probably situations where an internal-only system is needed, but I haven't run into one yet.