Registration systems and data structure
Event registration testing checklist
The registration form is built and looks right, and nobody has yet tried to break it the way real delegates will.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
Test registration with fictional delegates who behave badly on purpose: registering twice, picking the wrong category, filling a pool, cancelling and returning. For each test, write the expected result before you run it, then record what happened.
Run the tests on the live set-up or an identical copy, using addresses you control. Fix the cause of each failure, then repeat the test.
Fictional delegates for testing
Create a small cast and reuse it across tests, so results are comparable. Use email addresses you control, and mark every test record clearly so it can be removed before real numbers go to suppliers.
| Test delegate | Purpose |
|---|---|
| Aina Rahman, member | The ordinary member registration, start to finish. |
| Hafiz Karim, non-member | Non-member route and fee tier. |
| Mei Ling Tan, student | Evidence step and student category. |
| Raj Kumar, group booker for five | Group booking with unnamed seats and a substitution. |
| Siti Noor, duplicate of Aina with another email | Duplicate flag. |
| Test speaker | Hold-back place and no-fee route. |
Acceptance tests
| Area | Test | Expected result |
|---|---|---|
| Form | Submit with every required field empty, then with one missing. | Clear message on each missing field; nothing is saved. |
| Form | Use a long name, an apostrophe and accented letters. | Saved and shown correctly on the confirmation and in an export. |
| Category | Choose member with a number that is not on the list. | Held for review or handled by your rule. See member verification. |
| Duplicates | Register Aina twice with the same email. | Second entry blocked or flagged as your rules say. See duplicate detection. |
| Capacity | Fill a small test cap, then submit one more. | Delegate goes to the waitlist or sees a clear full message. See capacity controls. |
| Cancellation | Cancel a confirmed test registration. | Place released, status updated, confirmation sent. |
| Messages | Complete a registration and read the email on a phone. | Arrives, is readable, links work. See confirmation workflow. |
| Language | Register in each language your form offers. | Same fields and meaning in each. |
| Export | Export as each role that may export. | Only the permitted columns appear. See export permissions. |
| Check-in | Look up each test delegate at a trial desk. | Found by name and by reference; no one missing or twice. |
How to run the round
- Agree the test cast and the expected result for each test in writing.
- Run the tests in one sitting with one person recording results.
- Log each failure with the cause and who will fix it.
- Repeat the failed tests after the fix, and run the whole set again if a rule changed.
- Remove or clearly mark test records before any numbers go to suppliers.
What testing cannot tell you
A passed test shows your set-up behaves as you specified on that day. It does not show that the platform will behave the same under heavy load or after a change by the supplier. Re-run key tests after any change, and ask the platform's support what it documents about limits.
Worked example · Fictional example
A secretariat finds a duplicate gap one week before opening
Fictional organisation and figures, written to show the level of detail that is useful.
Persatuan Fiktif Jurutera Perkhidmatan tests its form with six fictional delegates. Aina is registered twice with the same email and the system blocks the second, as expected.
Siti, with another email but the same name and organisation, gets through with no flag. The secretariat records the gap, adds a review rule and repeats the test. A second failure is found: the confirmation email for a student does not mention that evidence is needed. The text is fixed and retested before registration opens.
Use this yourself
Registration test log
Copy one row per test. Fill the expected result before running, never after.
| Test | Test delegate | Expected result | Actual result | Pass or fail | Owner of fix | Retest date |
|---|---|---|---|---|---|---|
| Missing required field | Aina Rahman | Clear message, nothing saved | ||||
| Duplicate email | Aina Rahman | Second entry blocked or flagged | ||||
| Duplicate name, other email | Siti Noor | Flagged for review | ||||
| Cap reached | Hafiz Karim | Waitlist or full message | ||||
| Student evidence | Mei Ling Tan | Held until checked | ||||
| Group with unnamed seats | Raj Kumar | Seats held, naming deadline shown | ||||
| Cancellation | Hafiz Karim | Place released, message sent | ||||
| Export by role | Each role | Permitted columns only |
Handle it in-house, or bring in help?
Your team can usually handle this when
- A short form, a few categories and one person who knows the set-up.
- You have time for a full test round and a retest.
- The platform is one you have used before.
Outside planning help earns its fee when
- Many rules interact: categories, pools, groups, payments and waitlists.
- The platform is new to the team or has been changed by a supplier.
- Nobody has time to design the tests and record results properly.
Want the tests designed and run before you open?
A conference project lead can write the test cast and expected results with your secretariat, run the round, log each failure with an owner and re-run until the set-up matches your rules. Fixes to the platform itself belong to whoever supplies or configures it.
Questions organisers ask
Should we use real people to test registration?
Use fictional delegates with addresses you control. If real people test, tell them the entries are for testing and remove the records before real numbers are sent out.
When should testing happen?
Before registration opens, and again after any change to rules, categories, messages or the platform set-up.
Do tests include payment?
Only if your platform and finance contact provide a safe way to test payment. Check the platform's own documentation or support, and do not use real cards for testing without finance agreeing the route.
What should we do with test records afterwards?
Remove them or clearly mark them, and check that they do not appear in counts, exports or messages to suppliers.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.