Fundamentos de las Pruebas de Software. Proceso y técnicas de desarrollo de las pruebas de software

...

Principio 2: El testing en forma exhaustiva es imposible

El flujo de control de un sistema software no trivial como los que acostumbramos a utilizar en el día a día contiene miles de decisiones. Estas decisiones se pueden combinar entre ellas para dar lugar a una infinidad de posibles caminos. De entrada, probar todos los caminos es un problema inabordable.

Y eso si no tenemos en cuenta la prueba de requisitos no funcionales, como el rendimiento de un sistema ante una exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo, en un sistema bancario) para protegerse de usuarios malintencionados. Todo esto hace necesaria una estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos de calidad y de proyecto.

Principio 3: Probar en fases tempranas

Corregir un bug con una revisión en la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho menor a lo que costará corregir este bug cuando se detecte en una prueba de sistema, o peor aún, en una prueba de aceptación por el cliente. En demasiadas ocasiones existe una confianza excesiva en las pruebas de sistema, y todo el plan de pruebas (cuando existe) se reduce a estas. Se confía en que todos los componentes que no se probaron con una estrategia de pruebas unitarias y de integración se puedan entender bien a unos días del hito de entrega (cuando corregir un bug ya es demasiado caro, en lo que se denomina una prueba de integración “big-bang”). Curiosamente estas malas prácticas se realizan para ahorrar costes, y finalmente el coste de la no calidad cambia las tornas: siempre se acaba pagando en unos costes de mantenimiento excesivos.

Principio 4: Agrupamiento de los defectos

Entender esto es muy importante para plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se concentran en determinados puntos de un sistema software, no manteniendo una distribución uniforme a lo largo del mismo.

Conclusión: si encuentras un bug en un componente, es muy probable que haya más. Con lo que una posible estrategia sería centrarse en mejorar las pruebas de aquellos componentes para los que se han reportado un número mayor de bugs, para ser más eficaces a la hora de cazarlos en fases tempranas.

Principio 5: Paradoja “del pesticida”

Repetir siempre las mismas pruebas, con el correr del tiempo, no hará posible hallar nuevos bugs. Los casos de prueba se deben revisar periódicamente para evitar este fenómeno.

Se deben escribir nuevos casos de prueba que ejerciten diferentes partes del software para hallar nuevos y más defectos.

Principio 6: Las pruebas son dependientes del contexto

El testing se realiza de forma diferente en contextos diferentes. Definir los objetivos de las pruebas según el contexto.

Adaptar esos objetivos según el nivel de riesgo aceptable.

Principio 7: Falacia de la ausencia de errores

Encontrar y reparar los defectos no ayuda si el sistema desarrollado no cumple con las especificaciones.

Tampoco sirve el software desarrollado si el mismo no llena las necesidades y expectativas del usuario.

Técnicas de Diseño de Pruebas

Existen distintas técnicas de pruebas de software, con sus debilidades y sus puntos fuertes. Cada una de ellas es buena para encontrar un tipo específico de defectos. Las pruebas realizadas en distintas etapas del ciclo de desarrollo del software encontrarán diferentes tipos de defectos.

- Técnicas de pruebas dinámicas: Las técnicas de pruebas dinámicas ejecutan el software. Para ello introducen una serie de valores de entrada, y examinan la salida comparándola con los resultados esperados.

[pic 4]

- Basadas en la especificación: Son conocidas como técnicas de pruebas de caja negra o conducidas por entradas/salidas, porque tratan el software como una caja negra con entradas y salidas, pero no tienen conocimiento de cómo está estructurado el programa o componente dentro de la caja. Esencialmente, el técnico de pruebas se concentra en qué hace el software y no en cómo lo hace. Las técnicas basadas en especificaciones obtienen los casos de prueba directamente de las especificaciones o de otros tipos de artefactos que contengan lo que el sistema debería hacer.

- Basadas en la estructura: Las pruebas estructurales son una aproximación al diseño de casos de prueba donde las pruebas se derivan a partir del conocimiento de la estructura e implementación del software. Esta aproximación se denomina a veces pruebas de caja blanca. La comprensión del algoritmo utilizado en un componente puede ayudar a identificar particiones adicionales y casos de prueba, asegurando así un mayor rango de pruebas. Las técnicas más sofisticadas proporcionan, de forma incremental, una cobertura de código completa.

- Basadas en la experiencia: Las técnicas basadas en experiencia son aquellas a las que se recurre cuando no hay una especificación adecuada desde la que crear casos de prueba basados en especificación, ni hay tiempo suficiente para ejecutar la estructura completa del paquete de pruebas.

- Técnicas de control estáticas: Las técnicas de pruebas estáticas proporcionan una forma de mejorar la productividad del desarrollo del software. El objetivo fundamental de las pruebas estáticas es mejorar la calidad de los productos software, ayudando a los ingenieros a reconocer y arreglar sus propios defectos en etapas tempranas del proceso de desarrollo.

Las técnicas estáticas tienen que ver con el análisis y control de las representaciones del sistema, es decir de los diferentes modelos construidos durante el proceso de desarrollo de software.

La mayoría de las técnicas estáticas son técnicas de verificación que pueden probar cualquier tipo de documentación ya sea código fuente, o documentación y modelos de diseño, o especificación funcional o de requisitos.[pic 5]

- Revisiones: Las revisiones son una técnica estática que consiste en realizar un análisis de un documento con el objetivo de encontrar y eliminar errores.

El tipo de una revisión varía en función de su nivel de formalidad. En este caso, ‘formalidad’ se refiere a nivel de estructura y documentación asociada con