I think there's nothing quite like working against real software.
If you build on-premise software that includes an installer, it should be possible to identify past builds with defects, install the build on a machine somewhere, and then get the tester to re-execute a set of regression scripts, or do some exploratory testing, with the aim of then a) seeing if the find the known bugs (or bonus points for other bugs) and b) interviewing them afterwards to determine the process they went through in finding those bugs, and then what information they captured about them to relay to the rest of the team.
Alternatively if build web applications and doing continuous deployment, adjusting your development process to make it easy to deploy old/different builds also works really well for this.
In the .Net community the use of octopus deploy (http://octopusdeploy.com/) is gaining traction - this means you could retrieve old builds and then deploy them to a specific QC environment, where you could then "test" or train the tester on finding those kinds of issues + what diagnostic information to capture about them, so that wider team can reproduce/resolve the issue.
Working against real issues (preferably those which have since been resolved) means you can review the issue history/comments on the issue as well with them, to show how the issue was then progressed, resolved and re-tested.
As a developer I find this approach works well with up-skilling new developers on a team into how bugs are discovered, selected for fixing and re-tested too e.g. checkout an earlier branch, have a go at fixing the issue, then review what the actual commit for fixing it looked like, and how the fix was then retested etc. (which is normally all in the comment history of the issue in your defect tracker, hopefully!)