Gestión de PruebasGestión de Pruebas

Ingeniería del Software Ingeniería del Software

Universidad Mariano Universidad Mariano GalvezGalvez

Ing. David Gonzalez.Ing. David Gonzalez.

Gestión de PruebasGestión de Pruebas

Una de las sorpresas con las que suelen encontrar los Una de las sorpresas con las que suelen encontrar los Ingenieros de software es la enorme cantidad de tiempo y Ingenieros de software es la enorme cantidad de tiempo y esfuerzo que requiere la fase de pruebas. Se estima que la esfuerzo que requiere la fase de pruebas. Se estima que la mitad del esfuerzo de desarrollo de un software (tanto en mitad del esfuerzo de desarrollo de un software (tanto en tiempo como en gastos) se va en esta fase. Si hablamos de tiempo como en gastos) se va en esta fase. Si hablamos de software que involucran vidas humanas (medicina, equipos software que involucran vidas humanas (medicina, equipos nucleares, etc) el costo de la fase de pruebas puede nucleares, etc) el costo de la fase de pruebas puede fácilmente superar el 80%. fácilmente superar el 80%.

Como parte que es de un proceso industrial, la fase de pruebas Como parte que es de un proceso industrial, la fase de pruebas añade valor al producto que se maneja: todos los programas añade valor al producto que se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el tienen errores y la fase de pruebas los descubre; ese es el valor que añade. El objetivo específico de la fase de pruebas valor que añade. El objetivo específico de la fase de pruebas es encontrar cuantos más errores, mejor. es encontrar cuantos más errores, mejor.

Gestión de PruebasGestión de Pruebas

Es frecuente encontrarse con el error de afirmar que el Es frecuente encontrarse con el error de afirmar que el objetivo de esta fase es convencerse de que el programa objetivo de esta fase es convencerse de que el programa funciona bien. En realidad ese es el objetivo propio de las funciona bien. En realidad ese es el objetivo propio de las fases anteriores (¿quién va a pasar a la sección de pruebas fases anteriores (¿quién va a pasar a la sección de pruebas un producto que sospecha que está mal?).un producto que sospecha que está mal?).

La prueba ideal de un sistema sería exponerlo en todas las La prueba ideal de un sistema sería exponerlo en todas las situaciones posibles, así encontraríamos hasta el último situaciones posibles, así encontraríamos hasta el último fallo. Indirectamente, garantizamos su respuesta ante fallo. Indirectamente, garantizamos su respuesta ante cualquier caso que se le presente en la ejecución real. cualquier caso que se le presente en la ejecución real.

Esto es imposible desde todos los puntos de vista: humano, Esto es imposible desde todos los puntos de vista: humano, económico e incluso matemático. económico e incluso matemático.

Gestión de PruebasGestión de PruebasPrueba de UnidadesPrueba de Unidades

Normalmente cabe distinguir una fase informal antes de entrar en la Normalmente cabe distinguir una fase informal antes de entrar en la fase de pruebas propiamente dicha. La fase informal la lleva a fase de pruebas propiamente dicha. La fase informal la lleva a cabo el propio codificador en su despacho, y consiste en ir cabo el propio codificador en su despacho, y consiste en ir ejecutando el código para convencerse de que "básicamente, ejecutando el código para convencerse de que "básicamente, funciona".funciona".

Caja blancaCaja blanca

Se basa en encontrar errores o fallos al código.Se basa en encontrar errores o fallos al código.

Cobertura de segmentos Cobertura de segmentos

A veces también denominada "cobertura de sentencias". Por A veces también denominada "cobertura de sentencias". Por segmento se entiende una secuencia de sentencias sin puntos de segmento se entiende una secuencia de sentencias sin puntos de decisión. Como el ordenador está obligado a ejecutarlas una tras decisión. Como el ordenador está obligado a ejecutarlas una tras otra, es lo mismo decir que se han ejecutado todas las sentencias otra, es lo mismo decir que se han ejecutado todas las sentencias o todos los segmentos. o todos los segmentos.

En la práctica, el proceso de pruebas termina antes de llegar al En la práctica, el proceso de pruebas termina antes de llegar al 100%, pues puede ser excesivamente laborioso y costoso provocar 100%, pues puede ser excesivamente laborioso y costoso provocar el paso por todas y cada una de las sentencias. el paso por todas y cada una de las sentencias.

Gestión de PruebasGestión de PruebasCobertura de ramas Cobertura de ramas

La cobertura de segmentos es engañosa en presencia de La cobertura de segmentos es engañosa en presencia de segmentos opcionales. Por ejemplo: segmentos opcionales. Por ejemplo:

IF Condicion THEN EjecutaEsto; END; IF Condicion THEN EjecutaEsto; END;

Para afrontar estos casos, se plantea un refinamiento de la Para afrontar estos casos, se plantea un refinamiento de la cobertura de segmentos consistente en recorrer todas las cobertura de segmentos consistente en recorrer todas las posibles salidas de los puntos de decisión. Para el ejemplo posibles salidas de los puntos de decisión. Para el ejemplo de arriba, para conseguir una cobertura de ramas del 100% de arriba, para conseguir una cobertura de ramas del 100% hay que ejecutar (al menos) 2 veces, una satisfaciendo la hay que ejecutar (al menos) 2 veces, una satisfaciendo la condición, y otra no. condición, y otra no.

Estos criterios se extienden a las construcciones que suponen Estos criterios se extienden a las construcciones que suponen elegir 1 de entre varias ramas. Por ejemplo, el CASE. elegir 1 de entre varias ramas. Por ejemplo, el CASE.

Nótese que si lográramos una cobertura de ramas del 100%, Nótese que si lográramos una cobertura de ramas del 100%, esto llevaría implícita una cobertura del 100% de los esto llevaría implícita una cobertura del 100% de los segmentos, pues todo segmento está en alguna rama.segmentos, pues todo segmento está en alguna rama.

Gestión de PruebasGestión de PruebasCobertura de condición/decisión Cobertura de condición/decisión

La cobertura de ramas resulta a su vez engañosa cuando las La cobertura de ramas resulta a su vez engañosa cuando las expresiones booleanas que usamos para decidir por qué expresiones booleanas que usamos para decidir por qué rama tirar son complejas. Por ejemplo: rama tirar son complejas. Por ejemplo:

IF Condicion1 OR Condicion2 THEN HazEsto; END; IF Condicion1 OR Condicion2 THEN HazEsto; END;

Las condiciones 1 y 2 pueden tomar 2 valores cada una, Las condiciones 1 y 2 pueden tomar 2 valores cada una, dando lugar a 4 posibles combinaciones. No obstante sólo dando lugar a 4 posibles combinaciones. No obstante sólo hay dos posibles ramas y bastan 2 pruebas para cubrirlas. hay dos posibles ramas y bastan 2 pruebas para cubrirlas. Pero con este criterio podemos estar cerrando los ojos a Pero con este criterio podemos estar cerrando los ojos a otras combinaciones de las condiciones. otras combinaciones de las condiciones.

Gestión de PruebasGestión de PruebasCobertura de bucles Cobertura de bucles

Los bucles no son más que segmentos controlados por Los bucles no son más que segmentos controlados por decisiones. Así, la cobertura de ramas cubre plenamente la decisiones. Así, la cobertura de ramas cubre plenamente la esencia de los bucles. Pero eso es simplemente la teoría, esencia de los bucles. Pero eso es simplemente la teoría, pues la práctica descubre que los bucles son una fuente pues la práctica descubre que los bucles son una fuente inagotable de errores, todos triviales, algunos mortales. Un inagotable de errores, todos triviales, algunos mortales. Un bucle se ejecuta un cierto número de veces; pero ese bucle se ejecuta un cierto número de veces; pero ese número de veces debe ser muy preciso, y lo más normal es número de veces debe ser muy preciso, y lo más normal es que ejecutarlo una vez de menos o una vez de más tenga que ejecutarlo una vez de menos o una vez de más tenga consecuencias indeseables. Y, sin embargo, es consecuencias indeseables. Y, sin embargo, es extremadamente fácil equivocarse y redactar un bucle que extremadamente fácil equivocarse y redactar un bucle que se ejecuta 1 vez de más o de menos. se ejecuta 1 vez de más o de menos.

Gestión de PruebasGestión de PruebasPara un bucle de tipo WHILE hay que pasar 3 pruebas Para un bucle de tipo WHILE hay que pasar 3 pruebas

1-0 ejecuciones 1-0 ejecuciones

2-1 ejecución 2-1 ejecución

3-más de 1 ejecución 3-más de 1 ejecución

Para un bucle de tipo REPEAT hay que pasar 2 pruebas Para un bucle de tipo REPEAT hay que pasar 2 pruebas

1-1 ejecución 1-1 ejecución

2-más de 1 ejecución 2-más de 1 ejecución

Los bucles FOR, en cambio, son muy seguros, pues en su Los bucles FOR, en cambio, son muy seguros, pues en su cabecera está definido el número de veces que se va a cabecera está definido el número de veces que se va a ejecutar. Ni una más, ni una menos, y el compilador se ejecutar. Ni una más, ni una menos, y el compilador se encarga de garantizarlo. Basta pues con ejecutarlos 1 vez. encarga de garantizarlo. Basta pues con ejecutarlos 1 vez.

Gestión de PruebasGestión de PruebasNo obstante, conviene no engañarse con los bucles FOR y examinar su No obstante, conviene no engañarse con los bucles FOR y examinar su

contenido. Si dentro del bucle se altera la variable de control, o el contenido. Si dentro del bucle se altera la variable de control, o el valor de alguna variable que se utilice en el cálculo del incremento o valor de alguna variable que se utilice en el cálculo del incremento o del límite de iteración, entonces eso es un bucle FOR con trampa. del límite de iteración, entonces eso es un bucle FOR con trampa.

También tiene "trampa" si contiene sentencias del tipo EXIT (que También tiene "trampa" si contiene sentencias del tipo EXIT (que algunos lenguajes denominan BREAK) o del tipo RETURN. Todas algunos lenguajes denominan BREAK) o del tipo RETURN. Todas ellas provocan terminaciones anticipadas del bucle. ellas provocan terminaciones anticipadas del bucle.

Y en la práctica ¿qué hago? ¿Qué es una buena cobertura?Y en la práctica ¿qué hago? ¿Qué es una buena cobertura?Pues depende de lo crítico que sea el programa. Hay que valorar el Pues depende de lo crítico que sea el programa. Hay que valorar el riesgo (o coste) que implica un fallo si éste se descubre durante la riesgo (o coste) que implica un fallo si éste se descubre durante la aplicación del programa. Para la mayor parte del software que se aplicación del programa. Para la mayor parte del software que se produce en Occidente, el riesgo es simplemente de imagen (si un produce en Occidente, el riesgo es simplemente de imagen (si un juego fallece a mitad, queda muy feo; pero no se muere nadie). En juego fallece a mitad, queda muy feo; pero no se muere nadie). En estas circunstancias, coberturas del 60-80% son admisibles. estas circunstancias, coberturas del 60-80% son admisibles.

Las pruebas de caja blanca nos convencen de que un programa Las pruebas de caja blanca nos convencen de que un programa hace bien lo que hace; pero no de que haga lo que necesitamos. hace bien lo que hace; pero no de que haga lo que necesitamos.

Gestión de PruebasGestión de PruebasCaja negraCaja negra

Las pruebas de caja negra se centran en lo que se espera de un Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro. haciendo el módulo por dentro.

Las pruebas de caja negra se apoyan en la especificación de requisitos Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. para dar una medida del número de requisitos que se han probado. Es fácil obtener coberturas del 100% en módulos internos, aunque Es fácil obtener coberturas del 100% en módulos internos, aunque puede ser más laborioso en módulos con interfaz al exterior. En puede ser más laborioso en módulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura cualquier caso, es muy recomendable conseguir una alta cobertura en esta línea.  en esta línea.  

El problema con las pruebas de caja negra no suele estar en el El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables); sino en los es un número muy limitado en diseños razonables); sino en los datos que se le pasan a estas funciones.datos que se le pasan a estas funciones.

Gestión de PruebasGestión de PruebasA la vista de los requisitos de un módulo, se sigue una técnica A la vista de los requisitos de un módulo, se sigue una técnica

algebraica conocida como "clases de equivalencia". Esta algebraica conocida como "clases de equivalencia". Esta técnica trata cada parámetro como un modelo algebraico técnica trata cada parámetro como un modelo algebraico donde unos datos son equivalentes a otros. Si logramos donde unos datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia, reales a un conjunto reducido de clases de equivalencia, entonces es suficiente probar un caso de cada clase, pues entonces es suficiente probar un caso de cada clase, pues los demás datos de la misma clase son equivalentes. los demás datos de la misma clase son equivalentes.

Gestión de PruebasGestión de Pruebassi un parámetro de entrada debe estar comprendido en un cierto si un parámetro de entrada debe estar comprendido en un cierto

rango, aparecen 3 clases de equivalencia: por debajo, en y por rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango. encima del rango.

si una entrada requiere un valor concreto, aparecen 3 clases de si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango. equivalencia: por debajo, en y por encima del rango.

si una entrada requiere un valor de entre los de un conjunto, si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él. aparecen 2 clases de equivalencia: en el conjunto o fuera de él.

si una entrada es booleana, hay 2 clases: si o no.si una entrada es booleana, hay 2 clases: si o no.

los mismos criterios se aplican a las salidas esperadas: hay que los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases. intentar generar resultados en todas y cada una de las clases.

Gestión de PruebasGestión de PruebasEjemplo: utilizamos un entero para identificar el día del mes. Los Ejemplo: utilizamos un entero para identificar el día del mes. Los

valores posibles están en el rango [1..31]. Así, hay 3 clases: valores posibles están en el rango [1..31]. Así, hay 3 clases:

1-números menores que 1 1-números menores que 1

2-números entre 1 y 31 2-números entre 1 y 31

3-números mayores que 31 3-números mayores que 31

Durante la lectura de los requisitos del sistema, nos encontraremos Durante la lectura de los requisitos del sistema, nos encontraremos con una serie de valores singulares, que marcan diferencias de con una serie de valores singulares, que marcan diferencias de comportamiento. Estos valores son claros candidatos a marcar comportamiento. Estos valores son claros candidatos a marcar clases de equivalencia: por abajo y por arriba. clases de equivalencia: por abajo y por arriba.

Una vez identificadas las clases de equivalencia significativas en Una vez identificadas las clases de equivalencia significativas en nuestro módulo, se procede a coger un valor de cada clase, que no nuestro módulo, se procede a coger un valor de cada clase, que no esté justamente al límite de la clase. Este valor aleatorio, hará las esté justamente al límite de la clase. Este valor aleatorio, hará las veces de cualquier valor normal que se le pueda pasar en la veces de cualquier valor normal que se le pueda pasar en la ejecución real. ejecución real.

Gestión de PruebasGestión de PruebasLimitacionesLimitaciones

Lograr una buena cobertura con pruebas de caja negra es un Lograr una buena cobertura con pruebas de caja negra es un objetivo deseable; pero no suficiente a todos los efectos. Un objetivo deseable; pero no suficiente a todos los efectos. Un programa puede pasar con holgura millones de pruebas y programa puede pasar con holgura millones de pruebas y sin embargo tener defectos internos que surgen en el sin embargo tener defectos internos que surgen en el momento más inoportuno (Murphy). momento más inoportuno (Murphy).

Gestión de PruebasGestión de PruebasPruebas de IntegraciónPruebas de Integración

Las pruebas de integración se llevan a cabo durante la Las pruebas de integración se llevan a cabo durante la construcción del sistema, involucran a un número creciente construcción del sistema, involucran a un número creciente de módulos y terminan probando el sistema como conjunto. de módulos y terminan probando el sistema como conjunto.

Estas pruebas se pueden plantear desde un punto de vista Estas pruebas se pueden plantear desde un punto de vista estructural o funcional. estructural o funcional.

Las pruebas estructurales de integración son similares a las Las pruebas estructurales de integración son similares a las pruebas de caja blanca; pero trabajan a un nivel conceptual pruebas de caja blanca; pero trabajan a un nivel conceptual superior. En lugar de referirnos a sentencias del lenguaje, superior. En lugar de referirnos a sentencias del lenguaje, nos referiremos a llamadas entre módulos. Se trata pues de nos referiremos a llamadas entre módulos. Se trata pues de identificar todos los posibles esquemas de llamadas y identificar todos los posibles esquemas de llamadas y ejercitarlos para lograr una buena cobertura de segmentos ejercitarlos para lograr una buena cobertura de segmentos o de ramas. o de ramas.

Gestión de PruebasGestión de PruebasPruebas de IntegraciónPruebas de Integración

Las pruebas funcionales de integración son similares a las Las pruebas funcionales de integración son similares a las pruebas de caja negra. Aquí trataremos de encontrar fallos pruebas de caja negra. Aquí trataremos de encontrar fallos en la respuesta de un módulo cuando su operación en la respuesta de un módulo cuando su operación depende de los servicios prestados por otro(s) módulo(s). depende de los servicios prestados por otro(s) módulo(s). Según nos vamos acercando al sistema total, estas pruebas Según nos vamos acercando al sistema total, estas pruebas se van basando más y más en la especificación de se van basando más y más en la especificación de requisitos del usuario. requisitos del usuario.

Aguante (stress testing) Aguante (stress testing)

En ciertos sistemas es conveniente saber hasta dónde En ciertos sistemas es conveniente saber hasta dónde aguantan, bien por razones internas (¿hasta cuantos datos aguantan, bien por razones internas (¿hasta cuantos datos podrá procesar?), bien externas (¿es capaz de trabajar con podrá procesar?), bien externas (¿es capaz de trabajar con un disco al 90%?, ¿aguanta una carga de la CPU del 90?, un disco al 90%?, ¿aguanta una carga de la CPU del 90?, etc etc) etc etc)

Gestión de PruebasGestión de PruebasPruebas de IntegraciónPruebas de Integración

Las pruebas funcionales de integración son similares a las pruebas de Las pruebas funcionales de integración son similares a las pruebas de caja negra. Aquí trataremos de encontrar fallos en la respuesta de caja negra. Aquí trataremos de encontrar fallos en la respuesta de un módulo cuando su operación depende de los servicios un módulo cuando su operación depende de los servicios prestados por otro(s) módulo(s). Según nos vamos acercando al prestados por otro(s) módulo(s). Según nos vamos acercando al sistema total, estas pruebas se van basando más y más en la sistema total, estas pruebas se van basando más y más en la especificación de requisitos del usuario. especificación de requisitos del usuario.

Aguante (stress testing) Aguante (stress testing)

En ciertos sistemas es conveniente saber hasta dónde aguantan, bien En ciertos sistemas es conveniente saber hasta dónde aguantan, bien por razones internas (¿hasta cuantos datos podrá procesar?), bien por razones internas (¿hasta cuantos datos podrá procesar?), bien externas (¿es capaz de trabajar con un disco al 90%?, ¿aguanta externas (¿es capaz de trabajar con un disco al 90%?, ¿aguanta una carga de la CPU del 90?, etc etc).una carga de la CPU del 90?, etc etc).

Mutación (mutation testing) Mutación (mutation testing)

Es una técnica curiosa consistente en alterar ligeramente el sistema Es una técnica curiosa consistente en alterar ligeramente el sistema bajo pruebas (introduciendo errores) para averiguar si nuestra bajo pruebas (introduciendo errores) para averiguar si nuestra batería de pruebas es capaz de detectarlo. Si no, más vale batería de pruebas es capaz de detectarlo. Si no, más vale introducir nuevas pruebas. Todo esto es muy laborioso y introducir nuevas pruebas. Todo esto es muy laborioso y francamente artesano. francamente artesano.

Gestión de PruebasGestión de PruebasPlan de PruebasPlan de Pruebas

Un plan de pruebas está constituido por un conjunto de Un plan de pruebas está constituido por un conjunto de pruebas. Cada prueba debe dejar claro qué tipo de pruebas. Cada prueba debe dejar claro qué tipo de propiedades se quieren probar (corrección, robustez, propiedades se quieren probar (corrección, robustez, fiabilidad, amigabilidad, ...) dejar claro cómo se mide el fiabilidad, amigabilidad, ...) dejar claro cómo se mide el resultado especificar en qué consiste la prueba (hasta el resultado especificar en qué consiste la prueba (hasta el último detalle de cómo se ejecuta) último detalle de cómo se ejecuta)

Definir cual es el resultado que se espera (identificación, Definir cual es el resultado que se espera (identificación, tolerancia) ¿Cómo se decide que el resultado es acorde con lo tolerancia) ¿Cómo se decide que el resultado es acorde con lo esperado? esperado?

Las pruebas angelicales carecen de utilidad, tanto si no se sabe Las pruebas angelicales carecen de utilidad, tanto si no se sabe exactamente lo que se quiere probar, o si no está claro cómo exactamente lo que se quiere probar, o si no está claro cómo se prueba, o si el análisis del resultado se hace "a ojo". se prueba, o si el análisis del resultado se hace "a ojo".

Gestión de PruebasGestión de PruebasPlan de PruebasPlan de Pruebas

Estas mismas ideas se suelen agrupar diciendo que un caso Estas mismas ideas se suelen agrupar diciendo que un caso de prueba consta de 3 bloques de información: de prueba consta de 3 bloques de información:

-El propósito de la prueba -El propósito de la prueba

-Los pasos de ejecución de la prueba -Los pasos de ejecución de la prueba

-El resultado que se espera -El resultado que se espera

Y todos y cada uno de esos puntos debe quedar Y todos y cada uno de esos puntos debe quedar perfectamente documentado. Las pruebas de usar y tirar perfectamente documentado. Las pruebas de usar y tirar más vale que se tiren directamente, aún antes de usarlas. más vale que se tiren directamente, aún antes de usarlas.

Cubrir estos puntos es muy laborioso y, con frecuencia, Cubrir estos puntos es muy laborioso y, con frecuencia, tedioso, lo que hace desagradable (o al menos muy tedioso, lo que hace desagradable (o al menos muy aburrida) la fase de pruebas.aburrida) la fase de pruebas.

Gestión de PruebasGestión de Pruebas

Probar es ejercitar un programa para encontrarle fallos.Probar es ejercitar un programa para encontrarle fallos.Jamás se debería probar un programa con el ánimo de Jamás se debería probar un programa con el ánimo de mostrar que funciona; ese no es el objetivo. mostrar que funciona; ese no es el objetivo.

Un caso de prueba tiene éxito cuando encuentra un fallo.Un caso de prueba tiene éxito cuando encuentra un fallo.Lo gracioso no es encontrar un caso en el que el programa Lo gracioso no es encontrar un caso en el que el programa funciona perfectamente. funciona perfectamente.

Las pruebas debe diseñarlas y pasarlas una persona distinta de Las pruebas debe diseñarlas y pasarlas una persona distinta de la que ha escrito el código; es la única forma de no ser la que ha escrito el código; es la única forma de no ser "comprensivo con los fallos". "comprensivo con los fallos".

Hacer una "obra maestra" cuesta mucho esfuerzo y requiere Hacer una "obra maestra" cuesta mucho esfuerzo y requiere gran habilidad. Encontrarle fallos a una "obra maestra" gran habilidad. Encontrarle fallos a una "obra maestra" cuesta aún más esfuerzo y exige otro tipo de habilidad. cuesta aún más esfuerzo y exige otro tipo de habilidad.

Gestión de PruebasGestión de PruebasLas pruebas no pueden esperar a que esté todo el código escrito Las pruebas no pueden esperar a que esté todo el código escrito

para empezar a pasarlas. Deben irse pasando pruebas según para empezar a pasarlas. Deben irse pasando pruebas según se va generando el código para descubrir los errores lo antes se va generando el código para descubrir los errores lo antes posible y evitar que se propaguen a otros módulos. En realidad posible y evitar que se propaguen a otros módulos. En realidad el nombre "fase de pruebas" es engañoso, pues hay muchas el nombre "fase de pruebas" es engañoso, pues hay muchas actividades que se desarrollan concurrentemente o, al menos, actividades que se desarrollan concurrentemente o, al menos, no se necesita cerrar una fase antes de pasar a la siguiente. no se necesita cerrar una fase antes de pasar a la siguiente. Algunos autores llegan al extremo de afirmar que "primero hay Algunos autores llegan al extremo de afirmar que "primero hay que probar y luego codificar". Frase graciosa que se plasma en que probar y luego codificar". Frase graciosa que se plasma en aspectos mas concretos como que el programa se escriba aspectos mas concretos como que el programa se escriba pensando en que hay que probarlo. pensando en que hay que probarlo.

Si se detecta un fallo aislado, puede bastar una corrección Si se detecta un fallo aislado, puede bastar una corrección aislada. Pero si se detectan muchos fallos en un módulo, lo aislada. Pero si se detectan muchos fallos en un módulo, lo único práctico es desecharlo, diseñarlo de nuevo, y único práctico es desecharlo, diseñarlo de nuevo, y recodificarlo. La técnica de ir parcheando hasta que se pasan recodificarlo. La técnica de ir parcheando hasta que se pasan una serie de pruebas es absolutamente suicida y sólo digna del una serie de pruebas es absolutamente suicida y sólo digna del avestruz. avestruz.

Gestión de PruebasGestión de PruebasSi en un módulo (o sección de un programa, en general) se Si en un módulo (o sección de un programa, en general) se

encuentran muchos fallos, hay que insistir sobre él. Es muy encuentran muchos fallos, hay que insistir sobre él. Es muy habitual que los fallos se concentren en pequeñas zonas. habitual que los fallos se concentren en pequeñas zonas. Hay mil causas para que ocurra este efecto: Hay mil causas para que ocurra este efecto: código escrito por un programador malo código escrito por un programador malo código muy difícil código muy difícil código mal o insuficientemente especificado código mal o insuficientemente especificado código escrito en un mal día, con prisas, ... código escrito en un mal día, con prisas, ...

Además, cuanto más se parchea un trozo de código, tanto Además, cuanto más se parchea un trozo de código, tanto más ruinoso queda y susceptible a derrumbamientos. A la más ruinoso queda y susceptible a derrumbamientos. A la larga hay que acabar tirándolo y empezando de nuevo. larga hay que acabar tirándolo y empezando de nuevo.

Gestión de PruebasGestión de Pruebas

Las pruebas pueden encontrar fallos; pero jamás demostrar Las pruebas pueden encontrar fallos; pero jamás demostrar que no los hay. que no los hay.

Las pruebas también tienen fallos. Los errores son propios de Las pruebas también tienen fallos. Los errores son propios de los humanos: todo el mundo se equivoca. Si una prueba los humanos: todo el mundo se equivoca. Si una prueba falla, hay que revisar tanto lo que se prueba como lo que lo falla, hay que revisar tanto lo que se prueba como lo que lo prueba. No obstante, la experiencia muestra que (casi prueba. No obstante, la experiencia muestra que (casi siempre) hay más fallos el probado que en el probador. siempre) hay más fallos el probado que en el probador.