¿Qué etiquetas conviene guardar para probar?
Una de cada tipo que el código dice admitir, y luego una de cada estado que tiene que sobrevivir: virgen, formateada y vacía, llena, de solo lectura, protegida con contraseña, y una etiqueta muerta a propósito. La última es la que demuestra que la comprobación todavía puede fallar.
Una por tipo que declares
Empieza por lo que el código dice admitir. Un adhesivo de tipo 2, una tarjeta de tipo 4 y una etiqueta de tipo 5 cubren las tres familias que encuentra la mayoría de los proyectos, y la página de los tipos dice en qué norma descansa cada una. Si el despliegue incluye tarjetas MIFARE Classic, añade una: la clase que las lee es opcional en Android, así que un teléfono que no la tiene forma parte de la prueba.
Añade después una segunda etiqueta del mismo tipo y de otro chip, con otro tamaño de memoria. Es la manera más barata de cazar un número de página fijado en el código o una capacidad supuesta, el fallo del que trata la página de las diferencias entre chips.
Una por estado que tengas que sobrevivir
Una etiqueta tiene estados, y el código acaba encontrándolos todos. Virgen y sin formatear, que es lo que a veces es una etiqueta nueva, como explica la página del formateo. Formateada y vacía, que se lee como un mensaje de longitud cero. Llena, para que una escritura que no cabe falle como debe, el caso que cubre la página del tamaño.
De solo lectura, que rechaza la escritura para siempre, y protegida con contraseña, que la rechaza hasta que el código se autentica, las dos que separa la página de la protección. Las dos existen para comprobar que tus caminos de error dicen lo que corresponde en vez de decir lo mismo.
La etiqueta que no debe leerse nunca
Guarda una etiqueta genuinamente muerta, y etiquétala. La página de la etiqueta corrompida da la razón: es la única manera de saber que una comprobación detecta de verdad una etiqueta mala, y eso merece saberse antes de una tirada de producción y no después.
Una etiqueta dejada en un estado desconocido es lo contrario: produce fallos que nadie puede atribuir. Si el estado no está escrito encima, no forma parte del juego.
Etiquetadas, anotadas, guardadas
Escribe el estado en cada etiqueta y guarda la lista en un sitio donde el equipo pueda leerla, la misma disciplina que la página del seguimiento pide de un despliegue. Las contraseñas van también en esa lista, ya que una etiqueta de prueba protegida con una clave olvidada es una etiqueta de solo lectura con pasos de más.
Y recuerda que las etiquetas son la mitad del juego. Dos teléfonos por lo menos, uno de ellos sin las clases de tecnología opcionales, más un iPhone, ya que un mensaje que un analizador de Android acepta puede no hacer nada allí, la diferencia que cubre la página de los registros de iOS.
Preguntas frecuentes
¿Cuántas etiquetas necesita un juego de pruebas?
Menos de lo que parece: una por tipo que declares, una por estado que tengas que sobrevivir, y una etiqueta muerta. Con unas diez basta para casi todos los proyectos.
¿Para qué guardar una etiqueta muerta?
Para demostrar que la comprobación puede fallar. Una comprobación que no ha rechazado nunca nada no se ha probado.
¿Necesito etiquetas MIFARE Classic?
Solo si tu despliegue las tiene. La clase de Android que las lee es opcional, así que prueba también en un teléfono que no la tenga.
¿Y los teléfonos?
Dos teléfonos Android con controladores distintos y un iPhone. El juego de etiquetas encuentra los fallos de contenido, el de teléfonos los de plataforma.