Definiciones en el área de la medicina:
- Falso Negativo: un estudio indica enfermedad cuando no la hay.
- Falso Positivo: un estudio indica que todo está normal cuando el paciente está enfermo.
En nuestro caso el resultado mentiroso se da cuando un caso de prueba muestra un resultado que no es el correcto, ya sea que el software esté funcionando bien y el caso de prueba muestra que hay un error (falso negativo, el software está sano) ó que el software está funcionando mal y el caso de prueba muestra que está correcto (falso positivo).
O sea, el resultado de que sea negativo es falso, o el resultado de que sea positivo es falso.
Problemas ocasionados:
- Falso Negativo: la prueba dice que hay error y no lo hay, entonces perdemos tiempo buscando la causa del error hasta que nos damos cuenta que el error estuvo en el test, en el ambiente, los datos, etc.
- Falso Positivo: ¡hay errores y nosotros tan tranquilos! confiados de que esas funcionalidades están cubiertas, que están siendo probadas, y por lo tanto que no tienen errores (ojo!!)
Obviamente, ¡queremos evitar que los resultados nos mientan! No nos caen bien los mentirosos. Lo que se espera de un caso de prueba automático es que el resultado sea fiel y no estar perdiendo el tiempo en verificar si el resultado es correcto o no.
No queda otra que hacer un análisis proactivo, verificando la calidad de nuestras pruebas, y anticipando a situaciones de errores. O sea, ponerle un pienso a los casos de prueba, y que no sea solo record and playback.
Por un lado, para bajar el riesgo de que ocurran problemas de ambiente o datos de prueba, deberíamos tener un ambiente controlado, que solo sea accedido por las pruebas automáticas. Ahí ya nos vamos a ahorrar dolores de cabeza y el no poder reproducir problemas detectados por las pruebas, ya que si los datos cambian constantemente, no sabremos qué es lo que pasa.
Por otra parte, ¡deberíamos probar los propios casos de prueba! porque ¿quién nos asegura que estén bien programados? Al fin de cuentas el código de pruebas es código también, y como tal, puede tener fallas y oportunidades de mejora. Y quién mejor que nosotros los testers para probarlos.
Probando en busca de falsos negativos
Si el software está sano y no queremos que se muestren errores, debemos asegurarnos que la prueba está probando lo que quiere probar, y esto implica verificar las condiciones iniciales tanto como las finales. O sea, un caso de prueba intenta ejecutar determinado conjunto de acciones con ciertos datos de entrada para verificar los datos de salida y el estado final, pero es muy importante (y especialmente cuando el sistema que estamos probando usa bases de datos) asegurar que el estado inicial es el que esperamos.
Entonces, si por ejemplo vamos a crear una instancia de determinada entidad en el sistema, la prueba debería verificar si ese dato ya existe antes de comenzar la ejecución de las acciones a probar, pues si es así la prueba fallará (por clave duplicada o similar) y en realidad el problema no es del sistema, sino de los datos de prueba). Dos opciones: verificamos si existe, y si es así ya utilizamos ese dato, y sino, damos la prueba como concluida dando un resultado de "inconcluso" (¿o acaso los únicos resultados posibles de un test son pass y fail?).
Si nos aseguramos que las distintas cosas que pueden afectar el resultado están en su sitio, tal como las esperamos, entonces vamos a reducir mucho el porcentaje de errores que no son errores.
Probando en busca de falsos positivos
Si el software está enfermo, ¡la prueba debe fallar! Una posible forma de detectar los falsos negativos es insertar errores al software y verificar que el caso de prueba encuentre la falla. Esto en cierta forma sigue la idea del testing de mutación. Es muy difícil cuando no se trabaja con el desarrollador directamente como para que nos ingrese los errores en el sistema, y es muy costoso preparar cada error, compilarlo, hacer deploy, etc., y verificar que el test encuentra ese error. Muchas veces se puede hacer variando los datos de prueba, o jugando con distintas cosas. Por ejemplo: si tengo de entrada un archivo de texto plano, cambio algo para obligar a que falle y verifico que el caso de prueba encuentra esa falla. En una aplicación parametrizable, también se puede lograr modificando algún parámetro.
Siempre la idea es verificar que el caso de prueba se puede dar cuenta del error, y por eso intento con estas modificaciones hacer que falle. De todos modos lo que al menos podríamos hacer es pensarlo ¿qué pasa si el Software falla en esto? ¿este caso de prueba se daría cuenta, o me hace falta agregar alguna otra validación?
Ambas estrategias nos van a permitir tener casos de pruebas más robustos, pero ojo, ¿quizá luego sean más difíciles de mantener?
Disclaimer:
Por supuesto que no vamos a hacer esto con todos los casos de prueba que automaticemos, será aplicable a los más críticos, o a los que realmente nos merezca la pena, o quizá a los que sabemos que a cada poco nos dan problemas.
http://blog.abstracta.com.uy/2013/11/probar-un-caso-de-prueba-test-del-test.html
No hay comentarios.:
Publicar un comentario