Your exam handoff record
This record stays in this browser and is not sent to ZYNQO. Use a session label, not student names or passcodes. On a shared device, export your record and reset it when finished.
A practice-session test plan
Use a disposable three-question exam: one single-answer question, one written response if your paper uses it, and one question with an image. This makes it easier to distinguish a loading problem from an answer-saving problem. Keep a proctor view and a separate candidate profile open, and record observations from both.
Run the checks below with test data. Do not deliberately disconnect or change permissions during a real candidate's graded sitting. A rehearsal shows how a particular setup behaves; it is not a guarantee for every device or network.
| Scenario | What to observe | If it fails |
|---|---|---|
| Credentials rejected | Does the error distinguish incorrect details from a session that is not open? Can the proctor find the test registration? | Verify the session and registration details with the proctor. Do not ask a candidate to repeatedly guess a passcode. |
| Camera permission denied | Can the candidate find the browser's site-permission setting and retry? Does an approved alternative work? | Check browser and operating-system permissions. Resolve accessibility or privacy concerns with the institution before requiring a retry. |
| Connection drops after an answer | Record the answer and time before disconnecting. After reconnecting, compare the candidate view with the stored submission and proctor view. | Write down exactly what was lost or delayed. Agree on an extension or resit process before opening the graded exam. |
| Focus or face alert | Record whether a normal notification or a lighting change triggers a warning or pause, and how the candidate recovers. | Change the environment or provide an approved alternative. Do not interpret a detector error as evidence of intent. |
| Final submission | Compare the result with your known answers. Confirm that completion is visible to both candidate and proctor. | Keep the practice record and report the mismatch. Postpone if you cannot establish that submissions are preserved. |
Example handoff entry
Illustrative example, not a measured platform result: "Practice sitting B; school-managed laptop; browser version recorded by IT. Camera access denied by device policy. Candidate could reach the waiting room but could not complete the camera check. IT to confirm permission or the assessment lead to approve an alternative before Friday. Decision: hold this device group pending another rehearsal."
This is more useful than "camera broken": it identifies the stage, the observed failure, who can act, and what must happen before proceeding. Keep candidate identities and passwords in your institution's approved system, not in this worksheet.
Make the go / postpone decision
Postpone or provide an approved alternative when candidates cannot enter, submissions cannot be verified, a required accommodation is untested, or nobody owns the incident response. A completed checklist records your work; it does not certify that an exam is safe to run.
After the sitting, compare the actual incidents with the rehearsal notes. Add recurring problems to the next rehearsal and remove checks that no longer match the exam configuration. Keep the completed record with the assessment materials under your institution's retention policy.
For the candidate journey, see how ZYNQO sessions work. For monitoring limitations, read the screen-capture protection guide. Report an unclear instruction or a platform issue through contact and support.