Besides my work with computers, my other main interest is education, and I actually went so far as to obtain an Ed. M a few years back. One notion that stuck with me long after I left was that of authenticity, specifically authentic assessment. In contrast to the more prevalent high-stakes testing, authentic assessment is about testing people by making them do the thing itself rather than asking questions about it. The example we used in the class is that of a chef. If you were hiring a chef, how would you gauge their ability? It seems fairly obvious that you would have them cook you a meal. Contrast that with most classrooms, where they would be asked to draw a map to the grocery store or tell how many teaspoons are in a tablespoon. It is ridiculous in that context, but it's not too far from the reality of school testing.

I've discovered that authenticity is a generally useful concept, and shows up (although not under that name) in the testing literature. Proponents of Extreme Programming refer to test-first programming, where as you would expect, you write your tests first and then write the code. The idea is that the tests tell you how things ought to work and then you make the code fit that mode. I like this because it tries to impose an authenticity constraint on testing: make your tests do the things your code should do. I do this quite a bit, and I've discovered that the value of the approach is not so much in the fact that you find and fix bugs in your code quickly this way (you do) but that you find and fix bugs in your API and your thinking. If you write your API first, you will write tests that call it the way it was written and you aren't as likely to notice how awkward a certain set of method calls is, or how you never really need to use some methods. If you write your tests first with an imaginary "perfect" API, you will then code up that nice, simple, authenic interface. Try it some time on a new project. You will be surprised how different your methods end up looking since you have the freedom to write them as you might use them, rather than testing some predetermined API.
You can also impose authenticity on your debugging. Try to imagine how a real user would be using the system, and use the most realistic data available. Think through a day in the life of user including what other applications they might be running or how they might easily perform an action that you thought would never happen. You will be surprised how many times you can end up replicating an seemingly unreplicatable problem just by making it a little more real.