Why you should test a tag before deploying it
Because every expensive tag failure is discovered after application, and every one of them is visible in a five minute test beforehand. Write one tag, stick it to the real surface, and tap it with the oldest phone your audience is likely to carry.
What a test catches
Six failures, all of which are cheap now and expensive later.
Content that does not fit. A record type the target platform ignores. A tag family the target phone cannot read. A surface that detunes the tag. A case or a mount on the reader that prevents the tap. And a supplier who shipped something other than what was ordered.
Every one of these produces the same symptom in the field, which is a tag that does not work, and every one has a different cause and a different fix.
The five minute protocol
Read one tag from the batch before writing. Confirm the chip, the tag type, the state and the free space.
Write your content to that tag, then read it back. Confirm the record count, the record type and the complete content.
Stick it to the actual surface, not a desk. Metal, glass, a curved bottle, whatever the real object is.
Tap it with an Android phone and an iPhone, with the screen locked and unlocked, through whatever case the tester happens to have.
That is the whole procedure. It takes longer to describe than to perform.
Test with the worst case, not the best
The instinct is to test with the newest phone in the room, which is the one least likely to reveal a problem.
Background reading on iPhone depends on the model. Support for less common tag families varies between Android handsets. Read distance differs between devices, and a marginal tag will pass on a good phone and fail on an ordinary one.
If your audience is the public, the oldest phone you can borrow is a better test than the newest one you own. If your audience is staff, test with the actual devices they carry.
When to repeat it
Every batch, because suppliers substitute chips without announcing it and a batch that behaves differently from the last one is a common and invisible change.
Every time the content design changes, since a new record type is a new compatibility question.
And every time the surface changes. The same tag on cardboard and on a metal shelf are two different deployments, and only one of them was tested.
Frequently asked questions
Is one tag enough to test?
For content, format and compatibility, yes, since tags in a batch are near identical. For physical variation across a large order, testing a handful from different points in the delivery is more informative.
Do I need both an Android and an iPhone?
For anything the public will tap, yes. The two platforms handle record types differently, and a tag that works on one tells you nothing reliable about the other.
What if I cannot get the real surface to test on?
Test on the closest equivalent and treat the result as provisional. Metal in particular cannot be approximated, since the failure it causes is total rather than gradual.
Should I test after applying the tags too?
Yes, on a sample. Application itself can damage a tag by creasing it, and a tag that worked in the hand and fails on the wall was broken by the process rather than by the design.