7 Principios de las Pruebas de Software

Principio 1 – Las pruebas demuestran la presencia de defectos, no su ausencia

Nunca podremos decir que nuestro producto está libre de defectos. Tenemos un ejemplo en Samsung, una de las compañías de tecnología más grandes y entre las primeras en la lista de forbes manejando billones de dólares todos los años. Aún así uno de sus productos estrellas, el Samsung Galaxy Note 7 tuvo que ser retirado del mercado en octubre de 2016 a tan sólo 2 meses de su lanzamiento debido a que el dispositivo se incendiaba por sí solo, tanto en reposo como en uso. Uds creen que una compañía con estos niveles de recursos no probaron el dispositivo lo suficiente como para estar seguros de su éxito en el mercado y no arriesgar su reputación? Las pruebas pueden demostrar que hay presencia de defectos, pero no pueden probar que no los hay. Las pruebas reducen la probabilidad de que queden defectos ocultos en el software pero, incluso si no se encuentra ningún defecto, no constituye evidencia de corrección.

Principio 2 – Las pruebas exhaustivas no existen (o son imposibles)

Probar todo con todas las combinaciones de entradas y precondiciones no es factible, excepto en casos triviales. Pongamos el ejemplo de que tenemos que probar una parte del sistema que muestra la temperatura por ciudad, uds entran el código postal de la ciudad y se muestra la temperatura actual en esa ciudad. Tenemos en la actualidad 195 países en el mundo. Estados Unidos solamente tiene 19522 ciudades, así que pensemos en el cálculo para que nos demos cuenta de que probar si se muestra la temperatura correcta en todas las ciudades es una prueba que es demasiado costosa de realizar. O imaginen que necesitan probar una funcionalidad que incluye completar 10 campos de texto y cada uno de estos tiene unos 6 posibles valores, el número de combinaciones a probar sería 10 elevado a la 6 (),eso sería igual a 1 millón de combinaciones. Por esta razón, en lugar de intentar realizar pruebas exhaustivas, se debe realizar análisis de riesgos, utilizar técnicas de prueba y establecer prioridades para enfocar los esfuerzos dedicados a las pruebas.

Principio 3 – Las Pruebas Tempranas ahorran tiempo y dinero

Para detectar defectos de manera temprana, tanto las actividades de prueba estáticas como dinámicas deben iniciarse lo antes posible en el ciclo de vida de desarrollo de software. Las pruebas tempranas a veces son llamadas shift left (desplazamiento a la izquierda), porque son movidas a la izquierda en la línea de tiempo del proyecto, o sea que comienzan a realizarse tempranamente en el ciclo de vida. Durante la realización de pruebas tempranas, tratamos de encontrar defectos antes de que estos pasen a la próxima etapa de desarrollo del software. Según una investigación realizada por la compañía IBM, el costo de eliminación de defectos de software aumenta con el tiempo. Por lo que un defecto encontrado en la etapa de post producción cuesta 30 veces más que lo que costaría si fuera encontrado en la etapa de diseño Realizar pruebas tempranamente en el el ciclo de vida de desarrollo del software ayuda a reducir o eliminar el costo de los cambios.

Principio 4 – Agrupación de defectos

Usualmente la mayoría de los defectos descubiertos durante las pruebas previas al lanzamiento, o los defectos responsables de la mayoría de los fallos en operación se encuentran en un número reducido de módulos. Esta agrupación de defectos en estos módulos puede estar dada debido a que ese módulo posee una alta complejidad, porque ha sufrido más cambios que el resto y esto puede haber traído como consecuencia la inserción de nuevos defectos o por otras causas. Este fenómeno está muy relacionado con el principio de Pareto o también llamado la regla de 80/20, que aplicado a este problema podríamos decir que el 80% de los problemas se encuentran en el 20% de los módulos. Por lo que si se quiere descubrir la mayor cantidad de defectos, es útil emplear este principio y enfocar las pruebas en aquellas áreas o módulos donde se han encontrado más defectos y utilizar esta información como datos de entrada para el análisis de riesgos como se menciona en el principio 2. Claro esto no quiere decir que se descuiden las áreas donde se han encontrado menor densidad de defectos sino que se pruebe en la proporción adecuada.

Principio 5 – Tener cuidado con la paradoja del pesticida

Si repetimos las mismas pruebas una y otra vez, eventualmente estas pruebas ya no detectarán ningún defecto nuevo. Para detectar nuevos defectos, debemos actualizar las pruebas existentes y los datos de las pruebas y también escribir pruebas nuevas. (Las pruebas ya no son eficaces para encontrar defectos, al igual que los pesticidas después de un tiempo ya no son eficaces para matar insectos.) En algunos casos, como las pruebas de regresión automatizadas, la paradoja de los pesticidas tiene una resultado beneficioso, que es el número relativamente bajo de defectos de regresión.

Principio 6 – Las pruebas dependen del contexto

Las pruebas se realizan de manera diferente en diferentes contextos. Por ejemplo, el software de control industrial para la seguridad crítica es probado de forma diferente a una aplicación móvil de comercio electrónico. Las pruebas en los proyectos ágiles se realizan de forma diferente a las de los proyectos que adoptan un ciclo de vida secuencial. Otro ejemplo, el software de un avión de pasajeros se prueba de forma diferente que un sitio web con información estática. Aquí vemos que el nivel de riesgo es un factor fundamental cuando se definen los tipos de pruebas necesarios. Mientras más crítico es el sistema y más probabilidades de pérdidas de vidas humanas o de pérdidas económicas existe, más necesitamos invertir en las pruebas de software.

Principio 7 – Falacia de ausencia de errores

Algunas organizaciones esperan que los probadores puedan ejecutar todas las pruebas posibles y encontrar todos los defectos posibles, pero los principios 2 y 1, respectivamente, nos dicen que esto es imposible. Además, es una falacia (es decir, una creencia errónea) esperar que solo encontrando y solucionando un gran número de defectos se asegurará el éxito del sistema Por ejemplo, aún probando a fondo todos los requisitos especificados y corrigiendo todos los defectos encontrados se podría producir un sistema que es difícil de usar, que no cumple con las necesidades y expectativas de los usuarios, o que es inferior en comparación con otros sistemas de la competencia.