You will probably find it easiest to begin designing you test "base" (i.e. "master files" or relatively static data that will be used as your test starting point).

Read through your list of planned tests, and begin building the base data that they will need.

Use realistic data that you can show to your users - possibly by taking selected "live" data and modifying it to suit your test needs.

Avoid names like "Darth Vader" and "Mickey Mouse". Although they will work just as well in your test, this type of naming is regarded as juvenile by many people outside of your environment, and your tests will be considered less thorough and unprofessional.

If your application makes extensive use of "parameter files", make sure that the data in these files is set up correctly before building other test data. A single error in this type of file can cause many hours of wasted time.

If you are designing tests for an application which builds a new database then your test "base" for these tests may be nothing more than a set of empty files of tables. Your test cases would then consist of a set of validation tests for each database table, and then a series of test cases to actually enter data into your test base. This is a common way to begin testing a new application, rather than one that simply performs different functions on an existing database. If you build your test base this way, take a copy of the database after you have added all the data. This can then be used as a second test "base", when you want to run a series of tests that requires a "populated" database, and will save you the time required to re-run the database creation tests. (This assumes, of course, that no changes to the database or the database maintenance programs have been made, and hence re testing these functions is not necessary).

As you build your test base, you may find several points at which a copy of the database content could be a useful test base for a series of tests. In addition to the obvious ones of an empty database and "static" data only, outlined above, you may also find it useful to be able to begin a series of tests with a selection of "transaction" data already in the test base.

Once you have created the required data in your test "base", (which will probably take between 30% and 40% of the time you have allocated for all data creation tasks) you can then begin selecting the data that you will use for your "transaction" tests. This will almost certainly result in the need to go back (several times) and add more data to your test base, to provide the data that you will need for your tests. Don't be concerned about this need to go back several times. It is a natural and effective way to design your tests.

If you are having difficulties (e.g. the mind is a total blank!) put the work aside for a while, and come back to it later when you feel more creative. If time won't allow for this, then try following through some "live" processing that relates to what you want to test. This will often give you a good start.