Diez pruebas para nuestras aplicaciones si queremos pasar de grado. No, en serio.

Mi primera presentación en la reunión de investigación de desarrolladores que estamos llevando a cabo en mi empresa fue sobre pruebas en aplicaciones de software. Básicamente dividí la presentación en tres partes: introducción al tema, pruebas de aceptación, y por último, pruebas unitarias. De lo último ya he hablado anteriormente aquí y aquí, pero quería compartir algunos detalles sobre las pruebas de aceptación.

Sin caer en teoría alguna, vamos directo al grano. Usando tres diapositivas de la presentación puse un listado sobre todo lo que debería ser probado en una forma tan simple como la compuesta por una caja de texto para entrar una dirección de correo electrónico y un botón para enviar la información al servidor.

Y ahora bien, ¿qué importancia tiene saber esto? Pues simple: si eres un desarrollador y no te aseguras que este listado de posibles errores está cubierto, tu aplicación no estará libre de problemas y muchos de ellos pueden llegar a ser verdaderos dolores de cabeza. Si trabajas en el campo de QA, este es el listado con el ABC de todo aquello que puede fallar. No está todo, pero indiscutiblemente que es un buen comienzo.

Veamos la lista, y recordemos que estamos hablando de un campo para correo electrónico y un botón para enviar la forma al servidor:

Específicamente en la caja de texto:

1. ¿Es el valor entrado una dirección de correo válida?
2. ¿Es el número de caracteres válido? Nadie ha visto un email de 300 caracteres de longitud, ¿verdad?
3. ¿Es la dirección entrada una cadena vacía? ¿Permite la forma que se omita la dirección de email?
4. ¿Hay espacios en blanco al principio o al final de la dirección de email? Usualmente no querremos mandar un email a "  fake@email.com".
5. ¿Se está tratando de inyectar HTML o JavaScript a través de la caja de texto? ¿Qué tal un email como <strong>cannot@work.com</strong>?

Específicos al dominio en cuestión:

1. Chequear cada una de las reglas de negocio que posiblemente estén relacionadas con el correo electrónico. Por ejemplo, que no puedan existir dos personas con la misma dirección de email.
2. Chequear todo tipo de estilos relacionados con la caja de texto. Colores, alineación, etc.
3. Chequear el comportamiento de la forma cuando la caja de texto es colocada junto a otros campos. Por ejemplo, verificar el comportamiento del orden de los controles al presionar la tecla TAB sobre ellos.
4. Chequear cómo reacciona la forma si la sesión expira antes de enviar los resultados al servidor.
5. Chequear cómo se comportará la forma antes un error general de la aplicación. Por ejemplo, fallo de la red, la base de datos desconectada, etc. 

Y por si fuera poco, aquí hay dos elementos más de los que debemos preocuparnos:

1. Problema del "doble submit"
1. Producido al hacer click dos veces seguidas sobre un mismo botón que envía información al servidor.
2. La forma se envía dos veces.
3. Puede provocar un comportamiento no esperado, usualmente duplicando la información en la base de datos.
2. Reacción de la forma a errores
1. Cómo la forma recupera su estado trás un error
2. Cómo es mostrado el error (posición, estilos, mensaje, etc)
3. Manipulación en los datos (inconsistencias en la base de datos debido a la falta de uso de transacciones)

En total son 10 elementos a tener en cuenta, todos relacionados a una simple forma compuesta por un campo de texto y un botón. A medida que las cosas se complican un poco más, obviamente la lista crece y crece, pero por lo general los diez anteriores son el inicio que todos deberíamos tener en cuenta. Si esos fallan, ¿cómo no esperar que el producto sea un fracaso?

Me resulta chocante que a pesar de lo obvio que es todo esto aún hayan tantas aplicaciones que no aprueban ni siquiera tres de estas pruebas. Probarlo todo no es cómodo, seguro, pero al final del día es nuestro trabajo, así que nada mejor que empezar cuánto antes.