Most test cases are outlined in Features. However, tests should also be run to address potential errors. The following sections provide example errors that can be tested.

Interviewers can become impatient if a call is not returned quickly, resulting in the browser being closed while waiting for a call to be connected. If the interviewer immediately logs back in, using the same position, the call should still be connected and the sample displayed.

Timeouts occur when there are no questions submitted during the timeout interval (by default, 10 minutes). Refer to the registry key InterviewTimeout atHKEY_LOCAL_MACHINE\Software\SPSS\mrInterview\3\Interviewing). Timeouts are unlikely but can occur when there is a long page or when a respondent spends a long time discussing a question. To test this, set the InterviewTimeout registry key to a smaller value and then let a page sit during an interview for a time that is longer than the timeout interval. You can check if the record has timed out in the IVW log. Look for the "Interview timeout" message for the particular RespondentID. You can also use the Participants activity to see if the record has been moved to the TIMED_OUT queue. Once the record has timed out, answer the question and select Next. The interview should continue without error and the call should still be connected. It might take a bit longer to go to the next page because the interview has to be reloaded.

Interviewers might sometimes refresh the browser (using F5 or other methods) while interviewing. A browser refresh is treated as if the user navigated away from the page. This scenario is difficult to handle and leads to an error in most case. When this occurs, the interviewer must exit Interviewer Server Administration and restart the Phone Participants activity. It is imperative that the sample is not left in the ACTIVEqueue. Typically, the record is returned with an Abandoned call outcome.

The Phone Participants activity handles engine failures by first detecting the failure, then choosing a new engine. Suggestions for handling engine failures in the 3rd party dialing provider are discussed in Fail over. To test engine failures, establish a UNICOM Intelligence system with multiple interviewing engines. The engines can be on a single computer or multiple computers. It might prove easier to shut down the application pools for all but one engine, start the Phone Participants activity, and then request a contact (his forces the system to use the only available engine). Continue by starting the application pools for the other engines and then kill the process that hosts the original application pool (the process must be killed and not shut down). See Which IIS process is running the Web and Interview tiers for information on finding the Process ID for the associated application pool.

Once the process has been killed, submit the next question to cause the fail over (it is required that the call stay connected). In some cases, errors can occur if the interviewer tries a manually hangup or the interviewer requests the next contact.