When a student responds to a test item, that response is first saved in a saved response file (SRF), and then sent to the Pearson server. This is done to ensure student responses are not lost. The next test item will not be presented to the student until it is confirmed that the response to the current test item has been safely recorded in either an SRF or the Pearson server. The backup files are updated as a student navigates from the item or periodically when answering writing items.

If recorded successfully on the Pearson server, TestNav automatically deletes the response file from the SRF. This generally happens in milliseconds unless the connection to the Pearson server is congested or interrupted. On a busy network, with many testing computers attempting to send student test item responses concurrently, network congestion can occur. These backups prevent delays in testing while safeguarding student responses.

This setup task must be performed before test sessions are created. This task only needs to be done one time per test administration, unless a change is required. If that happens, the initial settings you enter now can be changed at any later date.

Whether you are using test content caching or not, you should check and configure your response file backup locations.

TestNav has a default setting for the primary location where it stores student response files. A primary save location is required. As a best practice, Pearson recommends using both a primary and secondary backup location.The default setting works well for most situations, but you may change it.

Choose backup locations that allow student accounts to have complete read and write access. Your options are to place the backup files in a directory on the computer the student is using (TestNav client) to take the test or in a directory on a network file server.

If you use a network file server as a backup location, whether primary or secondary:

  • Do NOT use spaces in the save location path.
  • Use a location that does not require authentication. If authentication is required, TestNav will not be able to access the shared location.
  • We recommend you:
    • Specify a mapped drive location, such as D:\TopDirectory\NextDirectory\SaveLocation
    • Do not use a Windows UNC (Uniform Naming Convention) or network path, such as \\ComputerName\SharedFolder\Resource unless necessary.
    • Use a location designated as a shared folder, a network location that can be accessed from all testing computers. Verify you can access the location from multiple testing computers.

Use these steps to edit the default settings for the primary backup location and add a secondary backup location, as desired.

  1. From Setup > TestNav Configurations, search to find configuration(s) or click the down arrow next to the Search button to reveal and select the option to show all results. Select the configurations(s) you wish to edit.

  2. Open the task list and select Create / Edit TestNav Configurations. Click Start.

     

  3. Change from the default settings for the primary backup location and add a secondary backup location, as desired. Click SaveFor information about the other settings available on this page, see Configure TestNav for Proctor Caching and Precache Content.

The following chart outlines the pros and cons of backup locations:

Backup Location Options

Pros

Cons

Local directory on testing computer (TestNav client)

Uses less internal network bandwidth

Test item delivery will not be delayed by waiting for files to be written to the networked drive

Backup file is not accessible from any other computer, so a student cannot easily move from one testing computer to another to complete a test without the need for an administrator to manually move the backup file.

Directory on network computer

Backup file may be accessed from other computers, which is important if you have a hardware failure on a testing computer

Uses more internal network bandwidth

Pearson recommends that your proctor caching computer is not set as the location for either primary or secondary SRF backups, as this may increase traffic to the proctor caching computer beyond appropriate levels.