[juangacovas]

This is the way, but connecting to production database is not always an option.

Let's say there is a problem when adding some type of record... You want to avoid, if possible, the creation of "test" records in production while reproducing the bug.

That's why I think we all end having some sort of inhouse tool that grabs a full snapshot of the database, or if not possible because of really big databases, just a sufficient dump of relevant data for the bug at hand (ie. just rows from some date, just some "customer" data, etc. to be able to mostly mimic the data environment).

Do whatever is needed to do your job: squash the bug. To do it you need to be able to reproduce it NOT in production (or you're lost in guess-temptative-fixes in production).

[zadkey]

It's true you can't always connect to prod backend db. Sometimes it's possible if you have a QA or DEV environment you can load it with prod data and test with that.