This is the fourth in a series of tips from my book, Put Your Data to Work: 52 Tips and Techniques for Effectively Managing Your Database, I’ve been asked by several people which of the tips are my favorites. So this series of blog posts focuses on five of them. Each of these tips is reproduced verbatim from the book.

Tip # 5 – Use a test environment

A test environment is an identical copy of your existing live database (or as near to identical as you can get) that allows you to “play” in the database without fear of creating bad data or damaging the live system. There are three critical reasons for having a test environment:

  1. Documentation. To provide effective documentation, you have to be able to work through the process you’re documenting in the same system that your users will use. You’ll need to grab screen-shots and describe, step-by-step, what the user can expect when executing a given process. The only way to do this effectively is within a test environment that mimics your live environment.
  2. Training. When training new users, training should always be done in a test environment. When you learn new things, you are already apprehensive about what you have to learn and whether you’ll be able to retain everything you’re told. If you train your users in a live environment, you’re simply adding to their apprehension and lowering their comprehension. When you train in a live environment, the only thing your users are thinking while you speak is, “If I push this button, will I break the whole system?” And then, “Will I get fired for breaking it?”  Train in a test environment, and let your users go wild. Exploring is an important part of learning; give staff the tools to explore and permission to “break” the system.
  3. Testing. Finally, a test environment is important for testing new processes. Whether it’s a new membership category, a different way to register for events, or doing fundraising for the first time, you need a test environment to test your new process, to see what kind of impact it has on the system. And of course, once you’ve established the new process, the first thing you’re going to do is document it, which will require, you guessed it, a test environment. (Ah, it all comes together now.)

One additional note: Make sure your test environment has been “refreshed” so that it reflects he same version of the software that users are using in a live environment, and try to have the data itself as recent as possible.

You can buy the book here (or here if you’re an ASAE member) in e-book or printed version.