Técnicas Avanzadas de Automatización de Pruebas II
Problemática de la comprobación y las pruebas
¿Cuánto esfuerzo en pruebas es suficiente?
Como todos los demás productos, tampoco el software está “siempre” libre de fallos. Las pruebas no pueden garantizar nunca la ausencia de fallos en un programa, sin embargo pueden encontrar y solucionar errores. En la práctica unas pruebas exhaustivas son rara vez posibles, sin embargo tampoco se puede garantizar para las partes probadas la ausencia total de errores.
Según el ámbito de aplicación y el tipo de error pueden ocasionarse daños graves. Por eso deben ser probadas “todas” las funcionalidades de un software de manera sistemática. Un proceso de pruebas puede considerarse en cierto sentido como destructivo y debe estar siempre encaminado a encontrar fallos.
La resolución de errores durante el desarrollo mejora el producto y reduce el coste de una eliminación posterior de los errores
Problemas generales de las pruebas
Ámbito de las pruebas
¡Ningún software complejo puede ser probado completamente! Incluso si se definieran todos los casos de prueba posibles su ejecución consumiría enormes recursos. En la práctica no sería posible la definición de todos los casos de prueba necesarios para unas pruebas exhaustivas, ya que habría que tener en cuenta todas las diferentes condiciones de entorno posibles. Además prácticamente en ningún caso se podrá decir con seguridad que se han definido todos los casos de prueba posibles.
Alcance
El alcance de las pruebas debe ser, por consiguiente, reducido – esto sucede en función de la relación entre Prioridades y Riesgo establecida utilizando formas de proceder sistemáticas. No está justificado un alto esfuerzo de pruebas para la eliminación de fallos “menores”. Implementar un programa sin comprobar los errores en sus características esenciales no tiene mucho sentido.
En la práctica se prueba mediante casos puntuales. En todo caso, esta prueba puntual se determina en la práctica de manera analítica.
Costes
Las pruebas originan altos costes dentro del desarrollo de software. Sobre todo en grandes proyectos de TI el esfuerzo para realizar las pruebas puede ser el mayor de todos respecto del esfuerzo total. Las pruebas tempranas contribuyen a la mejora del proceso de desarrollo y reducen de esta manera los costes (entre otras causas por la reducción de errores descubiertos en fases posteriores del desarrollo de software, ya que ahí el descubrimiento de fallos y su resolución conlleva un esfuerzo claramente mayor).
Los errores que no se encuentran en las pruebas también producen costes (Coste de Errores). Pérdidas de imagen, esfuerzos para las correcciones y compensación de daños amenazan al productor. Errores o pérdidas de datos y tiempos de inactividad son las consecuencias para los clientes.
En muchas situaciones es aplicable que los costes en las pruebas deberían ser menores que los posibles costes de los errores.
Principios generales de las pruebas
Principio 1: Las pruebas muestran la presencia de defectos
Las pruebas pueden mostrar la presencia de defectos. Las desviaciones respecto a los resultados previstos que se descubren durante las pruebas permiten localizar defectos existentes en el software. Las pruebas no pueden probar la ausencia de defectos. Las pruebas reducen la posibilidad de que queden defectos sin descubrir. La ausencia de fallos no prueba que el software sea correcto. El propio procedimiento de prueba puede contener errores. Las condiciones de pruebas pueden no estar bien preparadas para encontrar errores.
Principio 2: Las pruebas exhaustivas no son posibles
Pruebas exhaustivas. Es una estrategia de pruebas en la que se abarcan todas las posibles combinaciones de valores de entrada y precondiciones.
Explosión de casos de prueba. Define el aumento exponencial de esfuerzo y coste que aparece cuando se hacen pruebas exhaustivas.
Muestreo en las pruebas. Las pruebas deben incluir sólo un subconjunto de todos los valores de entrada posibles. Las entradas seleccionadas pueden escogerse de forma sistemática o aleatoria. En condiciones reales, se suele emplear el muestreo. Las pruebas de todas las combinaciones de entradas y precondiciones es viable desde el punto de vista económico sólo en casos triviales. En lugar de llevar a cabo pruebas exhaustivas, se debería utilizar el análisis de riesgo y el uso de priorizaciones para enfocar los esfuerzos de las pruebas.
Principio 3: Pruebas tempranas
Las actividades de prueba deberían iniciarse tan pronto como sea posible en el ciclo de vida de desarrollo y deberían tener objetivos concretos. Cuanto antes se descubra un defecto, menos costosa será su corrección. La máxima efectividad se alcanza cuando los errores se corrigen antes de ser implementados. Pueden probarse los documentos de requisitos conceptuales y las especificaciones
Los defectos que se descubren en la fase de concepción del proyecto se corrigen con mínimos esfuerzos y costes. La preparación de una prueba consume tiempo. La prueba no es sólo la ejecución. Pueden realizarse actividades de prueba (Diseño) antes de que se complete el desarrollo de software. Las actividades de prueba (considerando como tales las revisiones) deberían llevarse a cabo en paralelo a la especificación y el diseño de sw.
Principio 4: Bloques de defectos
Unos pocos módulos contienen la mayor parte de los defectos descubiertos durante la fase de pruebas o son responsables de la mayoría de los fallos de producción. Encuentre un defecto y encontrará más en los alrededores. Los defectos aparecen frecuentemente en grupos como las setas. Es una buena idea repasar el módulo en el que se ha encontrado un defecto. Los probadores deben ser flexibles. Una vez detectado un defecto, es una buena idea reconsiderar la dirección de las siguientes pruebas. La localización de un defecto debe ser revisada con un mayor nivel de detalle, ya sea incorporando nuevas pruebas o modificando las existentes.
Principio 5: La paradoja del pesticida (Bezier)
Si se repiten una y otra vez los casos de prueba, se llegará a que el mismo conjunto de casos de prueba no sirva para localizar nuevos defectos. Para superar esta “paradoja del pesticida”, los casos de prueba necesitan ser revisados de manera regular y se necesita escribir casos nuevos (y diferentes) para ejercitar diferentes partes del software o sistema y localizar más defectos. Cualquier método que se use para prevenir o encontrar bugs deja un residuo o bugs más sutiles, contra los que ese método no es efectivo. Repetir las pruebas bajo las mismas condiciones no es efectivo. Si se repiten una y otra vez las mismas pruebas no se encontrarán nuevos errores. Las pruebas deben ser revisadas regularmente. Es necesario repetir una prueba después de que se hagan cambios en el código. Las pruebas automatizadas pueden ser una ventaja si se usa regularmente un grupo de casos de prueba.
Principio 6: Las pruebas dependen del contexto
Las pruebas se llevan a cabo de manera diferente en contextos diferentes. Por ejemplo, el software critico desde el punto de vista de la seguridad de las personas (safety) se prueba de forma distinta que la seguridad de un portal de comercio electrónico (security). Las pruebas pueden tener distintos resultados en distintos contextos. Repetir las pruebas bajo las mismas condiciones no es efectivo. Diferentes objetos de prueba se prueban de forma distinta. El controlador del motor de un coche requiere distintas pruebas que las de una aplicación de comercio electrónico. Pruebas en el entorno de prueba vs pruebas en el entorno de producción. Las pruebas deben llevarse a cabo en un entorno separado al de producción. El entorno de prueba debe ser muy similar al de producción. Siempre habrá desviaciones entre ambos entornos.7
Principio 7: La falacia de la ausencia de errores
Localizar y corregir defectos no sirve de nada si el sistema construido no cubre las necesidades y expectativas de los usuarios. Unas pruebas adecuadas localizan los fallos más serios. En la mayoría de los casos, las pruebas no encontrarán todos los defectos del sistema pero si los más serios. Con esto solamente, no se prueba la calidad del software. La funcionalidad del software puede no cumplir las necesidades y expectativas de los usuarios. No se puede probar la calidad de un producto sólo con las pruebas, debe construirse desde el principio con la calidad requerida.
Otros principios (Myers)
La organización desarrolladora debiera evitar probar sus propios sistemas (hay una barrera mental que dificulta que encontremos defectos en aquello que construimos con esmero y dedicación). No debe planearse un esfuerzo de prueba bajo el supuesto de que no se encontrarán defectos. Probar es una tarea creativa e intelectualmente demandante.
Trabaja con nosotros
Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.