¿Cómo evitar falsos positivos y negativos en la automatización de pruebas?

Consideraciones para asegurar que los resultados obtenidos de la automatización de pruebas son confiables.

Cuando se trata de la automatización, uno de los temas más delicados son los resultados que no son reales, también conocidos como falsos positivos y falsos negativos. Los testers que han automatizado previamente saben que esto es un problema y aquellos que están a punto de comenzar, deben saber que es común que se encuentren con este problema.

¿Qué podemos hacer para evitar falsos positivos y negativos en la automatización de pruebas? ¿Cómo lograr que el caso de prueba se ejecute correctamente?

¿Qué es un falso positivo y falso negativo?

Estas definiciones provienen del área médica:

Falso positivo: un examen indica una enfermedad cuando no la hay.
Falso negativo: un examen indica que todo es normal cuando en realidad el paciente está enfermo.

Si traspasamos esto al área de testing de software, podríamos decir lo siguiente:

Falso positivo: cuando se ejecuta una prueba correctamente, la prueba indica que hay un error. Esto agrega muchos costos, ya que el tester buscará el error inexistente.
Falso negativo: cuando la ejecución de una prueba no muestra fallos pese a que existe un error en la aplicación. Esto, tanto como el falso positivo, puede deberse a un estado inicial incorrecto de la base de datos o a problemas relacionados con la configuración del entorno de prueba.

Si creemos que un falso positivo es un problema por el exceso de costos, con un falso negativo si bien hay errores, no somos conscientes de ellos y nos conformamos. Confiamos en que todas las funcionalidades están cubiertas y que se están probando, por lo que no deberían tener ningún error.

¡Obviamente queremos evitar que los resultados no sean reales! A nadie le gustan las mentiras. Se espera que los resultados de los casos de prueba automatizados sean fiables para que podamos estar seguros de que no perdemos el tiempo comprobando si los resultados son correctos o no.

La única opción es realizar un análisis proactivo, comprobando la calidad de nuestras pruebas y anticipándonos a posibles errores. Debemos estar pensando realmente en las pruebas y no simplemente haciendo un record & playback.

Para reducir el riesgo de problemas en el ambiente o en los datos, debemos tener un entorno rigurosamente controlado al que solo se pueda acceder mediante pruebas automatizadas. Con esto, ya nos estamos evitando importantes dolores de cabeza porque si los datos cambian constantemente, no podremos reproducir los problemas detectados por las pruebas y no podremos averiguar qué les pasa.

Además, ¡deberíamos comprobar los casos de prueba reales! Porque, ¿quién puede asegurarnos que están programados correctamente?

Al final del día, el código de prueba es código que puede presentar fallas o ser mejorado, ¿quién mejor que nosotros los testers para probarlos?

En busca de falsos positivos

Si el software está “en buenas condiciones” y no queremos que muestre ningún error, debemos asegurarnos de que el test está efectivamente probando lo que debe probar. Por tanto, debemos verificar tanto las condiciones de partida como las finales.

Es decir, un caso de prueba intenta ejecutar un conjunto determinado de acciones con ciertos input data para verificar los datos salientes y el estado final, pero es muy importante (especialmente cuando el sistema en prueba utiliza una base de datos) asegurarse de que el estado inicial es lo que esperábamos que fuera.

Si por ejemplo, estamos creando una instancia – de una entidad en particular en el sistema – la prueba debe verificar si esa información ya existe antes de comenzar la ejecución de las acciones a probar, porque si es así, la prueba fallará (debido a la duplicidad de datos o similar), pero en realidad el problema no está en el sistema sino en los datos de la prueba.

En este punto tenemos dos opciones: verificar si existe, de ser así, ya hemos probado con esa información, o finalizamos la prueba diciendo que el resultado es “inconcluso” (¿o son los únicos resultados posibles para aprobar y reprobar?).

Si nos aseguramos de que todas las cosas que podrían afectar nuestro resultado están en su lugar, tal como se esperaba, reduciremos el porcentaje de bugs que no son realmente errores.

En busca de falsos negativos

Si el software está “con errores”, ¡la prueba debe fallar! Una forma de detectar falsos negativos es insertar errores en el software y verificar que el caso de prueba encuentre dicho error. Esto va en línea con las pruebas de mutación.

Es muy difícil cuando no se trabaja directamente con el desarrollador para ingresar los errores en el sistema. También es bastante costoso gestionar cada error, compilarlo e implementarlo, etc., y verificar que la prueba encuentre ese error. En muchos casos, se puede hacer variando los datos de la prueba o jugando con diferentes cosas. Por ejemplo, si tengo un archivo de texto como entrada, puedo cambiar algo en el contenido del archivo para forzar que la prueba falle y verificar que el caso de prueba automatizado encuentre ese error. En una aplicación parametrizable, también podría lograrse modificando alguna variable de entrada.

La idea es verificar que el caso de prueba se dé cuenta del error y es por eso que intentamos que falle con estas alteraciones. De todos modos, lo que al menos podríamos hacer es pensar en lo que sucede si el software falla en este punto, ¿lo notará este caso de prueba o deberíamos agregar alguna otra validación?

Ambas estrategias nos permitirán tener casos de prueba más robustos, pero ten en cuenta lo siguiente: ¿serían más difíciles de gestionar o depurar más adelante? Por supuesto, esto no se aplicará a todos los casos de prueba que automatizamos, solo a los más críticos, o los que realmente merecen la pena, o probablemente los que sabemos que nos causarán problemas de vez en cuando.

¿Qué estás haciendo para prevenir falsos positivos y negativos en la automatización de pruebas? ¡Déjanos un comentario!