Authoring Tests
Authoring Tests
You author tests in the Zingasuite console at https://console.zingasuite.com. Every test you create belongs to your organisation and stays private until you decide otherwise.
The shape of a test
A Zingalify test is a tree:
- A test holds the title, description, language, kind, and delivery settings.
- Each test has one or more sections, which control ordering and time limits.
- Sections contain question groups. A group can be a plain bundle of questions or a shared-stimulus group that keeps a passage, image, case study, or video on screen while the candidate answers linked questions.
- Groups contain the individual questions (items).
You build and edit this tree in place. Add sections, drag questions around, adjust points and difficulty, and the draft updates live.
Canonical format and stable IDs
Behind the scenes every test is represented in a single canonical format that the authoring UI, the bulk importer, and the AI generator all share. Because they speak the same format, a test you draft by hand, import from a file, or generate with AI is the same kind of object — you can mix these approaches freely.
Every section, group, question, and option carries a stable ID — a permanent identifier that survives edits and reordering. Stable IDs are how responses are matched back to the exact question a candidate saw, and how AI generation records where each question came from.
Publishing freezes an immutable version
While you edit, you are working on the live draft. When you publish, Zingalify takes a complete snapshot of the tree and stores it as an immutable version. That version never changes.
This matters because:
- Candidate attempts are always tied to the published version they took, so a result stays reproducible even after you continue editing the test.
- Republishing after more edits creates a new version alongside the old ones; earlier versions remain intact for audit and comparison.
- If a fresh publish is identical to the previous version, Zingalify reuses it rather than creating a duplicate.
Depending on your organisation's publish policy, publishing may require review by a second person before a version goes live, and calibration or bias checks can be required first.
Private by default
New tests are private to your organisation. You choose when a test moves beyond your team. Visibility can be:
- Private — only your organisation.
- Group — shared within a defined group of organisations.
- Public — listed for wider use.
The standard library
Zingalify publishes a growing standard library of ready-made, professionally built tests. You can work with a standard test in three ways:
| Approach | What happens | When to use it |
|---|---|---|
| Use as is | Deliver the standard test directly, unchanged. | You want a proven instrument with no edits. |
| Compose (live-linked) | Reference standard content inside your own test; it stays linked to the published source and reflects its latest published version. | You want to combine standard content with your own and keep it current. |
| Fork | Take a frozen copy into your organisation that you can edit freely. | You need to customise wording, scoring, or structure. |
A fork is a snapshot: it captures the standard test at the moment you fork it and does not change when the original is updated. Live-linked composition, by contrast, follows the source. Choose a fork when you need editorial control, and live-linking when you want to stay in sync.
Reusable building blocks
Alongside tests, you can maintain an item bank of reusable questions, item pools for random-pool sections, rubrics for scoring open-ended answers, and an asset library for images, audio, and video. Organise everything with a nested category tree so large libraries stay navigable.