diplomado en calidad en el software derechos reservados, 1999 juan antonio vega fernández ¿qué es...

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are

Derechos Reservados, 1999

Juan Antonio Vega FernándezJuan Antonio Vega Fernández

¿Qué es Software Testing?¿Qué es Software Testing?

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Testing es el proceso de establecer confianza en que el programa o sistema hace lo que se supone que debería hacer.


Hetzel, 1973

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Testing es el proceso de ejecutar un programa o sistema con la intención de encontrar errores.


Myers, 1979

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are




• Testing es cualquier actividad enfocada hacia la evaluación de un atributo o capacidad de un programa o sistema para determinar que cumple con los resultados esperados.

Hetzel, 1983

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• La medida de la calidad en el software.


Hetzel, 1988

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



ProblemaProblema

• En una hoja de papel, escriba los casos de prueba que considere adecuados para probar el siguiente programa:– El programa lee 3 enteros. Estos enteros se

interpretan como la longitud de los lados de un triángulo. El programa imprime un mensaje que dice si el triangulo es escaleno, isóceles, equilátero o un triágulo inválido.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



ResultadosResultados

• ¿Se tiene un caso de pruebas que represente un triángulo escaleno válido (casos como 1, 2, 3 y 2, 5, 10 no son válidos)?

• ¿Se tiene un caso de pruebas que represente un triángulo equilátero válido?

• ¿Se tiene un caso de pruebas que represente un triángulo isóceles válido (casos como 2, 2, 4 no son válidos)?

• ¿Se tienen al menos 3 casos de pruebas que representen triángulos isóceles válidos tales que se prueben las 3 permutaciones de 2 lados iguales (e. g. 3, 3, 4; 3, 4, 3; 4, 3, 3)?

• ¿Se tiene un caso de prueba en donde un lado tiene valor de cero?

• ¿Se tiene un caso de prueba en donde un lado tiene un valor negativo?

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• ¿Se tiene un caso de prueba en donde la suma de 2 numeros sea igual al tercero (e. g. para 1, 2, 3 si el programa dice que es escaleno, el programa tiene un error)?

• ¿Se tienen tres casos de prueba para el punto anterior donde se prueben las 3 permutaciones posible (e. g. 1, 2, 3; 2, 1, 3; 3, 2, 1)?

• ¿Se tiene un caso de prueba en donde la suma de 2 números sea menor que el tercero (e. g. 1, 2, 4; 12, 13, 26)?

• ¿Se tienen tres casos de prueba para el punto anterior donde se prueben las 3 permutaciones posible (e. g. 1, 2, 4; 2, 1, 4; 4, 2, 1)?

• ¿Se tiene un caso de prueba en donde todos los lados son cero?

• ¿Se tiene al menos un caso de prueba en donde los valores no son enteros?


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• ¿Se tiene al menos un caso de pruebas en donde se especifica un número incorrecto de valores (por ejemplo dos en lugar de tres números)?

• ¿Para cada caso de prueba se especificó la respuesta esperada del programa además de los valores de entrada?


Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Por cada “sí” a las preguntas anteriores tiene un punto.

• En general los resultados son muy pobres.• Los más experimentados tienen un puntuaje de 8

en promedio.

• Si este programa fué difícil de probar, imagine un programa con más de 100 KLOC.

EvaluaciónEvaluación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Checar el programa contra las especificaciones.

• Encontrar errores en el programa.

• Determinar el grado de aceptabilidad para el usuario.

• Asegurarse de que un sistema está listo para usarse.

• Ganar confidencia de que el programa funciona.

• Mostrar que un programa funciona correctamente.

• Demostrar que los errores no están presentes.

• Entender los límites del rendimiento.

• Aprender lo que el sistema no puede hacer.

• Evaluar las capacidades de un sistema.

• Verificar la documentación.

• Convencerse a uno mismo de que el trabajo ya está terminado.

Qué es Software Testing Qué es Software Testing para el Practicantepara el Practicante

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• La mayoría de la gente tiene una visión incorrecta de lo que es testing, y esa es la principal causa de una mala prueba del software.

• Si la meta es demostrar que el programa no tiene errores, entonces subconscientemente estamos jalados hacia esa meta y tendemos a seleccionar datos de prueba que tengan una baja probabilidad hacer que el programa falle.

La Importancia La Importancia de la Definición de Testingde la Definición de Testing

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Unit Testing– Pruebas de programas individuales conformen

se van escribiendo.

• System Testing– Pruebas de grupos de programas integrados.

• Acceptance Testing– Pruebas para verificar que el programa esta

listo para usarse.

Niveles de Testing Niveles de Testing

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Objetivo– Confirmar que el módulo es codificado correctamente.

• Quién prueba– Usualmente el programador.

• Qué prueba– Funciones y código. Valores extremos y límites.

Prácticas Típicas Prácticas Típicas de Pruebas Unitariasde Pruebas Unitarias

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Prácticas Típicas Prácticas Típicas de Pruebas Unitariasde Pruebas Unitarias

• Cuando termina la prueba– Usualmente cuando el programador se siente confiable

con su código y siente que no tiene errores.

• Herramientas o ayudas– Generalmente no son utilizadas.

• Registros– Usualmente no se documentan.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Objetivo– Ensamblar módulos en un sistema funcional.

• Quién prueba– El líder del proyecto o el grupo de prueba.

• Qué prueba– Requerimientos y funciones del sistema, interfaces del

sistema.

Prácticas Típicas Prácticas Típicas de Pruebas del Sistemade Pruebas del Sistema

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Cuando termina la prueba– Cuando la mayoría de los requerimientos se cumplen.

• Herramientas o ayudas– Librerías del Sistema y librerías de casos de prueba.

Generadores de casos de pruebas, comparadores y simuladores.

• Registros– Bitácora de errores. Se mantienen casos de prueba.

Prácticas Típicas Prácticas Típicas de Pruebas del Sistemade Pruebas del Sistema

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Objetivo– Evaluar que el sistema esté listo para usarse.

• Quién prueba– Usuario final o su agente.

• Qué prueba– Funciones principales, documentación y

procedimientos.

Prácticas Típicas Prácticas Típicas de Pruebas de Aceptaciónde Pruebas de Aceptación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Cuando termina la prueba– Cuando el usuario se siente cómodo con el sistema o

cuando las pruebas terminan exitosamente.

• Herramientas o ayudas– Comparadores.

• Registros– Documentos formales e incluso legales.

Prácticas Típicas Prácticas Típicas de Pruebas de Aceptaciónde Pruebas de Aceptación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• De acuerdo al estándar IEEE/ANSI, 1990 [Std 610.12-1990]

– Mistake: Una acción humana que produce un resultado incorrecto. (Equivocación?)

– Fault: Un paso, proceso, o definición de datos incorrecto en un programa. El resultado de un “mistake” (Potencialmente puede llevar a un “failure”). (Falta?)

– Failure: Un resultado incorrecto. El resultado (o manifestación de la falta). (Falla?)

– Error: La cantidad por la cuál el resultado es incorrecto.

Definiciones BásicasDefiniciones Básicas

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Verificación, como se define por la IEEE/ANSI, es el proceso de evaluar un sistema o componente para determinar si los productos de una fase de desarrollo dada, satisfacen las condiciones impuestas al inicio de esa fase.

• Validación, como se define por la IEEE/ANSI, es el proceso de evaluar un sistema o componente durante o al final del proceso de desarrollo para determinar si se satisfacen los requerimientos especificados.

Verificación y ValidaciónVerificación y Validación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



¿Que es Software Testing?¿Que es Software Testing?

Testing = Verificación + Validación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Para cada tipo de verificación (requerimientos, diseño funcional, diseño interno, código) se debe establecer:– La actividad de verificación que será realizada.– Los métodos utilizados (Walk-through, inspecciones, etc)– Las áreas específicas del producto de trabajo que serán y que

no serán verificadas.– Los riesgos asociados con cualquier área que no será

verificada.– Asignar prioridades a las áreas del producto de trabajo que

serán verificadas.– Recursos, calendarzaciones, instalaciones, herramientas y

responsabilidades.

Planeación de la VerificaciónPlaneación de la Verificación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Para cada actividad de validación se debe establecer:– Los métodos de prueba.

– Las pruebas que serán automatizadas.

– Las herramientas de pruebas.

– El software de apoyo.

– La administración de la configuración.

– Los riesgos.

– Recursos, calendarzaciones, instalaciones, y responsabilidades.

Planeación de la ValidaciónPlaneación de la Validación

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Pruebas por RevisionesPruebas por Revisiones

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



¿Qué es una revisión?¿Qué es una revisión?

• Es cualquiera de una variedad de actividades que involucran:– Evaluaciones de cuestiones técnicas.– Evaluación de rendimiento por compañeros de

trabajo.

• El objetivo de cualquier revisión es obtener información confiable acerca del estado o calidad del trabajo.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Objetivos de una RevisiónObjetivos de una Revisión

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Tipos de RevisionesTipos de Revisiones

• Requerimientos

• Especificaciones

• Diseño

• Codificación

• Procedimientos

• Documentación

• Conversión

• Instalación

• Implementación

• Diseño de Pruebas

• Procedimientos de Pruebas

• Planes de Prueba

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Revisiones Revisiones Formales vs InformalesFormales vs Informales

• Las revisiones informales son cuando preguntamos a nuestros compañeros por su opinión.

• Las revisiones formales son cuando un grupo de personas es responsable de una evaluación exacta y de producir un reporte por escrito de los resultados.

• Las revisiones formales son las que se pueden utilizar como una técnica de pruebas.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• ¿Quién va a atender?

• Información requerida antes de que la revisión comienze.

• Precondiciones que deben estar terminadas antes de hacer la revisión.

• Lista de chequeo u otros indicadores de lo que se tiene que cubrir

• Condiciones finales o criterios que se tienen que cumplir para completar la revisión.

• Registro y documentos que se deben de mantener.

El plan de RevisiónEl plan de Revisión

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



¿Qué se logra ¿Qué se logra con las Revisiones?con las Revisiones?

• Las revisiones proveen de mecanismos primarios para la evaluación de la confiabilidad.

• Las revisiones resaltan las capacidades individuales.

• Las revisiones descubren baches y clases de errores de inmediato.

• Las revisiones dan retroalimentación temprana y preveen el surgimiento de problemas más serios.

• Las revisiones entrenan y educan a los participantes y tienen un efecto positivo importante en la competencia del personal.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Resultados esperados.

– Saber el propósito de la revisión. ¿Qué es lo que se va a probar o medir?

• Responsabilidades.

– Asigna responsabilidades claras para todos los participantes.

• Derechos individuales.

– Protege las opiniones y sentimientos individuales y no al comité.

Factores Críticos Factores Críticos de las Revisionesde las Revisiones

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



• Participantes.

– Escoger a la gente adecuada. Algunos internos al proyecto y otros externos al proyecto.

• Proceso estructurado.

– Procedimientos establecidos.

• Moderador.

– Con habilidades y entrenamiento.

• Registro.

– Evaluación y reporte escrito.

Factores Críticos Factores Críticos de las Revisionesde las Revisiones

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Revisiones de Revisiones de Productos de PruebasProductos de Pruebas

• Plan de Pruebas

• Especificaciones del Diseño de Pruebas

• Procedimientos de Pruebas

• Casos de Pruebas

• Reportes de Pruebas

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Integración de Revisiones de Integración de Revisiones de Pruebas y Revisiones de SoftwarePruebas y Revisiones de Software

Revisión deSoftware

Productos de Pruebas incluídos en la revisión

Requerimientos

Diseño

Diseño Detallado

Codificación

Implantación

Plan Maestro de PruebasEspecificación de las Pruebas de AceptaciónEspecificación de Pruebas del SistemaEspecificación de Pruebas de IntegraciónPlan Maestro ActualizadoEspecificación de Pruebas de Subsistemas

Procedimientos de Pruebas

Resultados de Pruebas y Reportes Sumarios

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



El enfoque de Pruebas del El enfoque de Pruebas del Ciclo de VidaCiclo de Vida

El Costo de las El Costo de las Pruebas en el Ciclo de VidaPruebas en el Ciclo de Vida

• Estudios han demostrado que durante el ciclo de vida del software se producen 60 errores por cada KLOC.

• Estudios también han demostrado que testing antes de la codificación es 50% efectivo en detectar errores y 80% efectivo después de la codificación.

• Estos estudios han demostrado que es 10 veces mas costoso corregir un error en codificación y 100 veces más costoso en producción.

• También se ha demostrado que 2 tercios de los errores ocurren antes de la codificación.

Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



Dip

lom

ado

en C

alid

ad e

n el

Sof

twar

eD

iplo

mad

o en

Cal

idad

en

el S

oftw

are



La Economía de las Pruebas La Economía de las Pruebas del Ciclo de Vida del Softwaredel Ciclo de Vida del Software

Requerimientos20 Errores

Diseño20 Errores

Codificación20 Errores

Testing - 80%err. reduction

Production0 defects

Cost Detect = 1

Cost Detect = 1

Cost Detect = 1

Cost Detect = 10

Cost Detect = 100

Ciclo de Vida Normal Ciclo de Vida con Testing

Costo Acumuladopor Pruebas

Costo Acumuladopor Pruebas

Errores acumuladospor KLOC

Errores acumuladospor KLOC

0

200

0

480

1,680

40

60

12

00 582

1010

15 25

18

4

42

182

diplomado en calidad en el software derechos reservados, 1999 juan antonio vega fernández ¿qué es...

Documents