Which tags should a developer keep for testing?
One of each type the code claims to support, then one of each state it has to survive: blank, formatted and empty, full, read only, password protected, and a tag that is dead on purpose. The last one is what proves the verification step can still fail.
One per type you claim
Start from what the code says it supports. A Type 2 sticker, a Type 4 card and a Type 5 tag cover the three families most projects meet, and the tag types page says which standard each one rests on. If the deployment includes MIFARE Classic cards, add one: the class that reads them is optional on Android, so a phone without it is part of the test.
Then add a second tag of the same type and a different chip, with a different memory size. It is the cheapest way to catch a hardcoded page number or an assumed capacity, the failure the chip differences page is about.
One per state you must survive
A tag has states, and code meets all of them eventually. Blank and unformatted, which a new tag sometimes is, as the formatting page explains. Formatted and empty, which reads as a message of length zero. Full, so a write that does not fit fails the way it should, the case the size page covers.
Read only, which refuses writing for good, and password protected, which refuses it until the code authenticates, the two the protection page separates. Both exist to check that your error paths say the right thing rather than the same thing.
The tag that must never read
Keep one tag that is genuinely dead, and label it. The corrupted tag page gives the reason: it is the only way to know that a verification step actually detects a bad tag, and that is worth knowing before a production run rather than after one.
A tag left in an unknown state is the opposite: it produces failures nobody can attribute. If the state is not written on it, it is not part of the set.
Labelled, recorded, kept
Write the state on each tag and keep the list somewhere the team can read, the same discipline the record page asks of a deployment. Passwords belong in that record too, since a protected test tag with a forgotten key is a read only tag with extra steps.
And remember that tags are half the set. Two phones at least, one of them without the optional technology classes, plus an iPhone, since a message an Android parser accepts can do nothing there, the difference the iOS records page covers.
Frequently asked questions
How many tags does a test set need?
Fewer than it sounds: one per type you claim, one per state you must survive, and one dead tag. Ten or so covers most projects.
Why keep a dead tag?
To prove the verification step can fail. A check that has never rejected anything has not been tested.
Do I need MIFARE Classic tags?
Only if your deployment has them. The Android class that reads them is optional, so test on a phone that lacks it as well.
What about the phones?
Two Android phones with different controllers and an iPhone. The tag set finds content bugs, the phone set finds platform ones.