How to Test an Online Election Before It Goes Live
Test your online election like a real voter: check the ballot, access methods, phones, selection rules, dates, receipts, and organizer workflow before launch.
By Votes.ng team · Published · Updated
Start here
Testing an online election should answer one question: If this were the real election today, would the organizer and voters know exactly what to do?
A quick glance at the organizer screen is not enough. Test the full path from invitation to final confirmation.
Use realistic test data
Create sample positions that resemble the Live ballot.
If the real election has eight positions, do not test one simple position and assume the rest will be fine. Long ballots reveal mobile scrolling, review, and attention problems that a tiny sample can hide.
Use clearly fake sample voters and candidates so nobody mistakes test activity for a real result.
Test on at least two device sizes
At minimum:
- small mobile screen
- normal laptop/desktop
If possible, test on both Android/Chrome and iPhone/Safari because voters may use either.
Look for:
- horizontal scrolling
- clipped buttons
- tiny tap targets
- headings wrapping badly
- selected state that depends only on color
- confirmation message hidden below the fold
Test the invitation path
Do not copy the ballot URL directly from the organizer screen and call that a voter test.
Use the same access method a real voter will receive.
For Votes.ng, test the personal voting link and the code-based fallback where applicable.
Confirm that:
- the link reaches the intended test election
- the code works with the expected voter details
- a wrong code fails safely
- old rotated access stops working
Read Voting Links and Voting Codes.
Test every selection rule
For each ballot position, try:
- valid selection
- no selection when the position requires one
- too many selections if multiple selection is possible
- explicit abstention if the election uses it
- review and change before final submission
The interface should make the allowed behavior clear before the voter makes a mistake.
Test a second submission
After the sample voter successfully submits, try to vote again using the same access.
The system should not create a second successful ballot.
This is an important acceptance test, not an attempt to attack the system.
Read How to Prevent Duplicate Voting.
Test the uncertain-network moment
You may not be able to reproduce every network failure, but you can still inspect the workflow.
Ask:
- Does the button clearly show that submission is in progress?
- Is accidental double-clicking handled?
- If the page is refreshed after success, does it avoid creating another vote?
- Does the receipt/confirmation help the voter know the submission was recorded?
Test dates and time zone
Check the election from the perspective of someone who did not configure it.
Make sure the opening and closing times are displayed clearly and use the intended time zone.
If voters are in several countries, communicate the time zone explicitly rather than assuming everyone interprets a local time the same way.
Test organizer actions too
The organizer should know how to:
- see the election state
- see turnout without named choices
- handle a voter who cannot access the ballot
- understand when the voter list becomes locked
- close/finalize the election according to the workflow
- find result verification information
A voter-facing test is incomplete if the organizer does not know what will happen on election day.
Proofread against the approved source
Compare the test ballot with the official candidate/position list.
Check:
- spelling
- position assignment
- order
- selection limit
- description
- candidate information, if used
Do not proofread only from memory.
Separate test data from Live data
Test votes should never be counted as real election votes.
Votes.ng keeps Test participation separate from Live voting. Test votes do not become Live votes, and resetting Test activity does not remove Live ballots. Structural changes are restricted during the Live lifecycle.
This separation is one reason to use Test mode instead of creating fake Live voters in a real election.
Use a written launch checklist
Before paying or opening Live voting, confirm:
- final voter list approved
- ballot proofread
- all positions tested
- voter access tested
- second submission blocked
- phone layout checked
- dates/time zone checked
- organizer support route ready
- result process understood
Then have a second person review the checklist if the election is important to the organization.
Testing is cheaper than correction
Most test findings are ordinary: a misspelled name, wrong date, missing voter, unclear instruction, or confusing mobile layout.
Those are easy to fix before launch and potentially difficult after real ballots exist.
Continue with How to Run an Online Election, or see the Votes.ng How it works page for the product flow.