To the extent we're doing things right, we should be scientific.
Pass Vagrant boxes that are build from known sources (can rebuild from scratch with single command if you have the time). Intermediate result (a built system) is solely a performance enhancement.
Speed in this stuff is so critical because it allows for fast iteration.
"I have a full pull of the production data from 5 weeks ago in my development database."
If you make a change to some code and that code changes that data, how do you get back to a known data state? Download the items table again?
Seeds! Seeds for Pete's sake! Or at least pull a coherent subset of data from production. It should take less than a minute. Ideally it would take a second!
A coherent subset of data that supports given scenarios is small. Because it's small, it takes only about a minute to download the subset using pg_transfer. However, since the speed of our repeatability is so critical, I persist the results to a database dump, and then reload that dump over and over, since it only takes seconds. If you additionally run scenario-specific seeds on top of that base data set, you have a fast, repeatable, and predictable way to get yourself to known states with production data quickly. This type of workflow facilitates high-speed discovery, and, for lack of a better name, play.
The most painful thing about QA is having a dataset with an unknown state (or having to establish that state by moving through a slow or cumbersome UI). Make no mistake, we must QA, whether we define it as a strict process or just fumble around through ill-defined scenarios we keep in our heads. I prefer to push much of that QA process into tests, which when fast are often faster, and certainly more repeatable and predictable than REPL-based hackery and debugging. They are not fast at Instacart, however, which is highly problematic. Barring a good testing story, we have to test by hand, and by test, of course I mean QA, but that can be aided somewhat by the methods I describe above.
At 32:00 through 35 he talks about speed in the testing https://youtu.be/VD51AkG8EZw?t=32m6s ... how many "thoughts" you can have in a day. It mirrors my thinking exactly.