calidad en el proceso de software:...

1

Calidad en el proceso de software: Pruebas

Humberto Cervantes MacedaMayo 2008

2

IEEE-829 y Metodología STEP

IEEE-829 Especifica la forma de un conjunto de documentos a ser usados en ocho etapas definidas de la prueba de software

Plan de pruebasEspecificación de diseño de pruebasEspecificación de casos de pruebasEspecificación de procedimiento de pruebasReporte de transmisión de items de pruebasBitácora de pruebasReporte de incidentes de pruebasResumen de pruebas

STEP describe una guía de los procesos a seguir para producir documentos de IEEE 829

3

Definiciones de pruebas

1979: “The Art of Software Testing”, G. MyersLa realización de pruebas es el proceso de ejecutar un programa o sistema con el fin de encontrar errores

Pruebas realizadas al final del desarrollo1983: “Complete guide to software testing”, B. Hetzel

La realización de pruebas es cualquier actividad orientada a la evaluación de un atributo de un programa o sistema. La realización de pruebas es la medición de la calidad del software

2002: “Systematic software testing”, Craig & JaskielLa realización de pruebas es un proceso concurrente de de ingeniería, uso y mantenimiento de productos de pruebas (testware) con el fin de medir y mejorar la calidad del software que se está probando

4

Estado de la práctica (2002)

En general se sigue un enfoque secuencialRequerimientos → Diseño → Código → Pruebas

Problema de dejar las pruebas hasta el finalRetraso en eldescubrimiento de defectosMucho re-trabajoPoco tiempo para realizar pruebas sifecha de entrega es fija

Lo ideal es un enfoque de pruebaspreventivas

La realización de pruebas puede mejorarla calidad del software si comienza de formatemprana en el ciclo de vida

5

Dificultades asociadas a la prueba

Requerimientos ambiguos o incorrectos

Calendarios apretados

Necesidad de entrenamiento de los probadores

En resumen: realizar pruebas es difícil

6

Metodología STEP

Proceso de Prueba y Evaluación SistemáticaEs uno de los modelos líderes para realización de pruebas efectivas en la industria

EvaluaciónLa sub-disciplina de la ing. de software preocupada con determinar si los productos de software hacen lo que se supone que deben hacer.

Técnicas principales de evaluación incluyenAnálisisRevisiónPruebas

7

Pruebas preventivas

Inicialmente se veía como algo que sucedía después de la construcción del software

Hoy en día es un proceso que se realiza en paralelo con construcción y mantenimiento e incorpora

Planeación: determinar riesgos y escoger estrategiasAnálisis: determinar objetivos y requerimientos de pruebasDiseño: especificar pruebas a ser desarrolladasImplementación: construir procedimientos y casos de pruebaEjecución: correr las pruebasMantenimiento: actualizar las pruebas

8

Pruebas preventivas

En RUP, las pruebas también inician de forma temprana

9

Tres fases principales de STEP

Planear la estrategiaSelección de la estrategia y especificación de los niveles y el enfoque

Adquisición de los productos de prueba

Especificación de los objetivos detallados de pruebas, diseño e implementación de los conjuntos de pruebas

Medición del comportamiento

Ejecución de las pruebas y evaluación del software y el proceso

10

Actividades de las tres fases

Planear la estrategiaEstablecer plan maestro de pruebasDesarrollar planes detallados de pruebas

Adquisición de los productos de pruebaInventario de los objetivos específicos basados en requerimientos, diseño e implementaciónDiseño de las pruebasImplementación de los planes y diseños

Medición del comportamientoEjecutar las pruebasVerificar qué tan adecuado es el conjunto de pruebasEvaluar el software y el proceso de pruebas

11

Tiempos de las actividades

12

Uso de documentos IEEE 829-1998Plan de pruebas

Usado para el plan maestro de pruebas y planes específicos a los niveles

Especificación de diseño de pruebasUsado en cada nivel para especificar la arquitectura del conjunto de pruebas y las trazas de cubrimiento

Especificación de los casos de pruebaUsado cuando se requiere para describir casos de prueba o scripts de automatización

Especificación de procedimientos de pruebaUsado para especificar los pasos para ejecutar un conjunto de casos de prueba

Bitácora de pruebasUsado cuando se requiere para registrar ejecución

Reporte de incidentes de pruebasUsado para describir anomalías que ocurren durante las pruebas o la producción

Reporte de resumen de pruebasUsado para reportar completud de pruebas a cierto nivel

13

4 roles principales

AdministradorResponsable de proveer dirección y coordinación de pruebas así como comunicar información clave a las partes

AnalistaResponsable de realizar planeación detallada, inventario de objetivos de pruebas y áreas de recubrimiento, diseño y especificación de pruebas y revisión y evaluación de pruebas

TécnicoResponsable de implementar procedimientos y conjuntos de pruebas, de acuerdo a los diseños generados por el analista, para ejecutar las pruebas y verificar resultados y para registro y realización de bitácoras de pruebas

RevisorProvee revisión y opinión sobre todas las etapas y productos de prueba en el proceso

14

Análisis de riesgos

El análisis de riesgos juega un papel fundamental ya que el análisis y priorización de riesgos permite concentrar el esfuerzo de pruebas

El análisis de riesgos permite determinarQué probarLa prioridad de realizar pruebasNivel de detalle de las pruebas

15

Actividades del análisis de riesgos

16

Fase de planeación

17





18

Planeación de pruebas

ObjetivoEl objetivo de la planeación de pruebas es de cubrir los aspectos importantes de la estrategia de pruebas, utilización de recursos, responsabilidades, riesgos y prioridades

La planeación de pruebas ocurre a distintos nivelesEl plan inicial es el plan maestro de pruebas cuyo objetivo es orquestar pruebas a todos los niveles

UnitarioIntegraciónSistemaAceptación

Dependiendo de la complejidad del proyecto, será necesario crear planes individuales para cada nivel

19

Calendarización

Planeación tempranaLa planeación debe comenzar tan pronto como sea posible. En general, el plan maestro de pruebas debe comenzar a ser realizado al mismo tiempo que las especificaciones de requerimientos y el plan de proyecto

Los distintos planes inician en las distintas fases del desarrollo

20

Contenido del plan de prueba1. Identificador del plan de prueba2. Tabla de contenido3. Referencias4. Glosario5. Introducción6. Items de prueba7. Problemas asociados a riesgos de software8. Características a ser probadas9. Características a no ser probadas10. Enfoque (o estrategia)11. Criterios de aceptación / rechazo de items12. Criterios de suspensión y requerimientos para reinicio13. Entregables de prueba14. Tareas de prueba15. Necesidades del entorno16. Responsabilidades17. Necesidades de equipo y entrenamiento18. Calendario19. Riesgos y contingencias de planeación20. Aprobaciones

21

Detalle de plan

1. Identificador de plan de pruebaNumero utilizado para identificar una versión del plan de prueba, su nivel y la versión del software al que pertenece

2. Tabla de contenido3. Referencias

A otros documentos tales como plan de proyecto (referenciados a partir de ID)

4. Glosario5. Introducción

Describe alcance de plan de pruebas6. Items de prueba

Describe qué será probado dentro de los alcances del plan

Ej. Este plan cubre la versión 1.1 de la aplicación

22

Detalle de plan

7. Problemas asociados a riesgosEsta sección discute el análisis de riesgos con el propósito de determinar cuál será el enfoque de pruebas

Qué se va a probarQué no se va a probar

Lo que se prueba es más importante que qué tanto se prueba

8. Características a ser probadasSurgen a partir de priorización de análisis de riesgo

9. Características a no ser probadasDescribe características que presentan pocos riesgos y no requieren de pruebas

23

Detalle del plan

10. Enfoque o estrategiaEsta sección contiene una descripción de cómo serán realizadas las pruebas (enfoque) y describe cualquier problema que tenga un impacto importante en el éxito de las pruebas y en el proyecto (estrategia).La estrategia se ve influenciada por distintos aspectos

24

Detalle del plan

10. Enfoque o estrategia (sigue)Esta sección debe presentar los detalles acerca de

Decisiones de la metodología a seguir para realizar las pruebasRecursos dedicadosDecisiones sobre cobertura de pruebasRecorridos e inspecciones (parte de evaluación)Administración de la configuraciónColecta y validación de métricasHerramientas y automatizaciónCambios al planJuntas y comunicación

11. Criterios de aceptación o rechazoTípicamente descrito en término de porcentaje de casos de prueba pasados

25

Detalle de plan

12. Criterios de suspención y reqs. para reinicioDescribe condiciones que puedan llevar a detener realización de pruebas así como aquellas que permitan retormarlas

13. EntregablesLista de los productos derivados de las pruebas que serán desarrollados y mantenidos

14. Tareas de pruebaLista de tareas necesarias para realizar pruebas

15. Necesidades de entornoIncluye todas las necesidades a nivel del entorno que facilitan la realizaición de pruebas

16. ResponsabilidadesMatriz de responsabilidades (establecer entorno de pruebas, realización de prueba unitaria, etc...)

26

Detalle del plan

17. Necesidades del equipo y entrenamientoDescribe la cantidad de gente requerida y las habilidades que deben poseer

18. Calendario19. Planeación de riesgos y contingencias

Provee información sobre toma de decisiones acerca de la planeación

20. AprobacionesFirmas de aprobación

27





28

Planeación detallada

La información general del proyecto se usa para desarrollar el plan maestro

Información más específica se usa para desarrollar los planes detallados específicos a cada nivelNiveles típicos: unidad, integración, sistema, aceptación

Sistemas complejos pueden requerir mas niveles

La creación de un plan de pruebas para un nivel específico requiere comprender las consideraciones únicas asociadas a cada nivel

Riesgos, recursos, equipo, etc...El plan de pruebas se describe usando el mismo templete que para el plan maestro

29

Modelo en V

Los planes específicos a los niveles se escriben generalmente en orden inverso a la ejecución

30

Pruebas de aceptación

Se basan en requerimientos y tienen como objetivo demostrar que se han cubierto los requerimientos

Idealmente son desarrolladas por usuariosEjecutadas por los usuarios y probadores

Las pruebas de aceptación no son generalmente demasiado detalladas

La parte detallada se realiza en las pruebas de sistema

Se realizan enUn espejo del entorno de producciónCon datos realesDatos en grandes cantidades

31


Responsabilidades de usuariosDefinir requerimientosIdentificar riesgos del negocioCrear, actualizar y/o revisar el plan de aceptaciónDefinir pruebas realistas basadas en escenariosProveer datos realistas de pruebasEjecutar las pruebasRevisar la documentaciónRevisar la salida de las pruebasProveer criterios de aceptación

32


Trazabilidad de requerimientosAsegura que uno o más casos de prueba cubren cada requerimiento

33


Control de cambioSe debe tener cuidado con respecto a los problemas que aparecen en las pruebas de aceptación y estos deben someterse al proceso usual de control de cambios

Evitar a toda costa hacer reparaciones de último minuto ya que el no evaluar los impactos puede tener consecuencias desastrosas

34


Criterios de aceptaciónTienen mucha importancia ya que básicamente dan “luz verde” al sistema

Ejemplos de criteriosNo puede haber errores de severidad media o altaNo puede haber más de 2 bugs en una característica o un total de 50 bugsAl menos un caso de prueba debe pasar para cada requerimientoLos casos de prueba 23, 25 y 38-52 deben todos pasar8 de cada 10 usuarios deben ser capaces de realizar un caso de uso en menos de una horaEl sistema debe ser capaz de procesar 1000 peticiones por hora

35

Pruebas de sistema

CaracterísticasEscritas y realizadas por equipo de pruebasRealizadas en una máquina similar a la de producciónSe usan conjuntos de datos grandes reales y provistosConsumen la mayor parte de recursos de pruebasPueden extenderse durante un periodo considerableDeben ser tan detalladas como permitan los recursos y los riesgosEn esta etapa se realizan pruebas de carga, desempeño, confiabilidad y otros atributos de calidadEl conjunto de pruebas comprende normalmente la suite completa de pruebas de regresión

36

Pruebas de sistema

Escritas por el equipo de pruebas

Generalmente, el plan de pruebas se escribe en cuanto se tiene una versión inicial relativamente completa de los requerimientos

37

Pruebas de sistema

Áreas a incluir en matriz de trazabilidadRequerimientosCaracterísticasCapacidadConcurrenciaInteroperabilidadInstalaciónLocalizaciónDesempeñoRecuperaciónConfiabilidadUso de recursosEscalabilidadUsabilidad

38

Pruebas de sistema

Ejemplo de estrategia para implementar cambiosLas dos primeras semanas, todas las peticiones de cambio serán implementadas en un build cotidiano que se llevará a cabo a las 5:30 pm

Las dos semanas siguientes, los administradores de pruebas, de desarrollo, de configuración y representantes de usuarios se reunirán a las 10:00 cada Martes y Jueves para priorizar todas las solicitudes de cambio o correción de errores abiertas. Ellos decidirán también que errores que ya hayan sido corregidos serán promovidos al entorno de pruebas del sistema

Para las dos semanas finales de prueba del sistema, sólo correcciones de errores que “detienen el show” serán implementadas en el entorno de pruebas

39

Pruebas de sistema

Ejemplos de criterios de aceptaciónTodos los resultados de las pruebas unitarias y de integración están documentadasNo hay bugs de alta severidadDebe haber cobertura de 100% de las instruccionesDebe haber una cobertura de 100% de las especificaciones del programaLos resultados de un recorrido del código están documentados y son aceptables

40

Pruebas de integración

Es el nivel de prueba que se realiza para asegurar que los distintos componentes de un sistema interactuan e intercambian datos correctamente y funcionan de manera cohesiva.

Pruebas realizadas por el grupo de desarrollo para asegurar que las unidades trabajan de manera apropiada en su conjunto.

En particular a nivel de las interfaces.Las pruebas de integración pueden ocurrir a distintos niveles.

41


Cuándo se escribe el plan?El proceso de planeación de las pruebas de integración puede comenzar tan pronto como el diseño comienza a estabilizarse.

Escritura y realizaciónLas pruebas son generalmente escritas y realizadas por los desarrolladores

Algunas veces es necesario realizar 'stubs' y 'drivers' (simulación de componentes de bajo y alto nivel respectivamente)

OrdenEs conveniente realizar pruebas de integración sobre los componentes que presentan más riesgo inicialmente o que están en el camino crítico

42


ProblemáticasQué modulos u objetos deben ser ensamblados o probados en conjunto?Cuáles son los sub-ensambles funcionales?Cuáles son las características críticas?Qué tantas pruebas son apropiadas?Cuánto código de soporte (scaffolding) es requerido?Cómo aislar los problemas?Cómo coordinar con las pruebas de sistema y pruebas unitarias?

43


Ejemplo

Los componentes oscuros están en el camino crítico que deben pasar pruebas de integración antes de que la función Make Reservation pueda pasar a la fase de pruebas de sistemaSi alguno de los componentes A, C, K o N no están completos, la función no podrá ser ejecutada sin incluir stubs o drivers

44


Administración de la configuraciónEn etapas iniciales de pruebas de integración, la administración de la configuración se puede realizar de manera informal, pero debe formalizarse conforme avanza el tiempo

Entorno de pruebasGeneralmente las pruebas de integración se llevan a cabo en el entorno de desarrollo

45

Pruebas unitarias

Como su nombre lo indica, son pruebas a nivel de los componentes individuales

Dificultades de realizaciónPrisas de sacar código relega pruebas unitariasReticencia de los desarrolladores a realizar pruebas unitarias

No les gusta sentir que son “medidos”Falta de entrenamiento de los desarrolladores

46

Pruebas unitarias

Adminstración de la configuraciónEs conveniente tener en pie un procedimiento de control de código para que las pruebas se realicen de forma sistemática

Se debe evitar procedimientos demasiado rígidos

Colecta de métricasLa colecta de métricas a nivel unitario permite identificar áreas problemáticas desde el principio

Ejemplo: componentes que tienen muchos problemas son identificados como de alto riesgo

Los desarrolladores pueden tener reticencia a la colecta de métricas

Esto puede impedir la identificación de áreas problemáticas

47

Pruebas unitarias

Se recomiendaReutilizar productos de pruebaRealizar revisiones de las pruebas unitariasRealizar pruebas unitarias antes de codificación

48

Síntesis

La planeación detallada debe realizarse desde el principio y proceder en forma paralela con el ciclo de vida de desarrollo para ser efectiva

Se recomienda iniciar con los niveles básicos de prueba definidos por la IEEE

AceptaciónSistemaIntegración yUnidad

Posteriormente se pueden ajustar los niveles agregando o quitando niveles

49

Caso de pruebas

Los casos de pruebas consisten de entradas, salidas y orden de ejecución

EntradasIncluye datos de entrada de distintas fuentes, el estado en que que está el sistema (precondiciones) y detalles del entorno de ejecución

SalidasIncluye datos de salida, postcondiciones y detalles del entorno de ejecución

Orden de ejecuciónEn general existen dos tipos: secuencial o independiente

50

Caso de pruebas

Ejemplo de templete de pruebas para casos de usohttp://www.geocities.com/xtremetesting/TCtemplate.html

51

Tipos de pruebas

Caja negraLas pruebas de caja negra son una estrategia en la cual las pruebas se basa únicamente en los requerimientos y especificaciones. No requieren conocimiento de las partes internas del sistema.

Caja blancaEn las pruebas de caja blanca las pruebas se basan en los caminos internos, la estructura y la implementación del software que se está probando. En general, este tipo de pruebas requieren habilidades de programación.

Caja grisEn este enfoque se ven dentro de la caja únicamente para comprender globalmente como está implementada y se procede a realizar pruebas de caja negra.

52

Análisis y diseño de pruebas

Analisis y diseño de pruebasEs el proceso de determinar objetivos de prueba y la manera de organizar los objetivos para soportar la ejecución eficiente.

Los objetivos de pruebas son categorías de cosas que se desean probar.

La elección de la técnica a usarse se basa en la naturaleza del sistema, el riesgo de implementación, el nivel de prueba y los conocimientos de los probadores

53

Inventarios

Los objetivos de pruebas son categorías amplias de cosas que deben ser probadas para una aplicación en particular

Por ejemplo: Para una aplicación de seguros de automóvil, los objetivos podrían ser: tipos de autos, lugar de accidente, datos del conductor, etc...

Los inventarios son la lista de cosas que deben ser probadas para cada uno de los objetivos

Por ejemplo: Para datos del conductor, nombre, numero de póliza de seguro

54

Proceso para diseño de pruebas

1.- Obtener materiales de referenciaCon el fin de crear inventario a partir de la documentación del sistema

2.- Juntar un equipoEste equipo multidisciplinario será responsable de buscar objetivos de pruebas

3.- Determinar objetivos de pruebaEn esta etapa se busca solamente hacer una lista de los objetivos de prueba

4.- Priorización de objetivosLa priorización de los objetivos se basa en los riesgos y en el alcance

5.- Crear inventariosSe detallan los objetivos y se crean listas detalladas

55


6.- Crear una matriz de seguimiento de inventarioEn las columnas se ponen casos de prueba existentes

56


7.- Identificar pruebas para áreas no cubiertasModificar casos de prueba existentesAgregar casos de prueba nuevos

57


8.- Evaluar si los casos de prueba cubren el detalle de los objetivos (el inventario)

9.- Dar mantenimiento a la matriz de pruebaConforme hay cambios en el software

58

Pruebas de caja negra

Proceso de pruebasSe analizan especificaciones o requerimientosSe escogen entradas válidas e inválidasSe determinan valores esperadosSe construyen pruebas para las entradas seleccionadasSe ejecutan las pruebasLas salidas obtenidas se comparan con las esperadasSe determina si la aplicación funciona correctamente

AplicaciónA todos los niveles. A un nivel de granularidad elevado estamos obligados a hacer este tipo de pruebas

VentajasNo se puede probar todo, pero las pruebas de caja negra permiten realizar pruebas a partir de subconjuntos de casos que son efectivos para encontrar defectos.

59

Técnicas de caja negra y blanca

Caja negraPruebas de clase de equivalenciaPruebas de valores de fronteraPruebas de tablas de decisiónPruebas de paresPruebas de transición de estadosPruebas de análisis de dominioPruebas de Casos de uso

Caja blancaPrueba de control de flujoPrueba de flujo de datos

60

Prueba de equivalencia de clase

Qué esEs una técnica usada para reducir el número de casos de prueba a un nivel manejable mientras se mantiene una cobertura razonable

EjemploSe quiere que un programa de recursos humanos tenga la siguiente lógica de negocio con respecto a la edad de los candidatos

0–16 No contratar16–18 Contratar a tiempo parcial18–55 Contratar a tiempo completo55–99 No contratar

Se debe probar las posibilidades de 0 a 99?A menos que se tuviera tiempo y recursos ilimitados no!

61


Si suponemos una implementación del tipo

No es necesario probar los valores 0,1,2...16Todos son igual de buenosEstos rangos son llamados clases de equivalencia

Una clase de equivalencia es un conjunto de datos que es tratado de forma igual y produce resultados idénticos

if (edad >= 0 && edad = 16 && edad = 18 && edad = 55 && edad

62


Un grupo de pruebas forman una clase de equivalencia cuando se espera que

Todos prueben lo mismoSi uno encuentra un error, los demás tambiénSi uno no encuentra un error, los demás tampoco

Usando clases de equivalencia, el ejemplo anterior permite reducir de 100 a 4 el numero de casos de pruebaQué pasa si se pasa un valor inválido, se debe probar?

Depende de si el módulo esta diseñado por contratoPre-condiciones y post-condiciones bien establecidas. Sólo se prueba con pre-condiciones establecidas.

De otra forma, el módulo puede estar diseñado de forma “defensiva” (se protege de entradas erróneas)

En ese caso se deben hacer pruebas al respecto

63


Aplicabilidad y limitacionesApropiado para sistemas en los cuales los valores de entrada del sistemas se encuentran dentro de rangosSe aplica a los cuatro niveles

64




65

Pruebas de valores de frontera

Las pruebas de valores de frontera se enfocan en las fronteras ya que ahí residen muchos problemas

La mejora manera de encontrar estos problemas es a través de las inspecciones

En este ejemplo podría resultar en una corrección de los requerimientos

if (edad >= 0 && edad = 16 && edad = 18 && edad = 55 && edad

66

Pruebas de valores de frontera

Realización1.- Identificar clases de equivalencia2.- Identificar sus fronteras3.- Realizar pruebas para cada frontera con un valor por debajo, uno por encima y uno en la frontera

AplicabilidadVa de la mano con las pruebas de clase de equivalenciaSe aplica en sistemas en los cuales muchos de los datos de entrada se ubican dentro de rangos o conjuntosSe aplica a los cuatro niveles de prueba

67




68

Pruebas de tablas de decisión

Las pruebas de tablas de decisión se usan para registrar reglas complejas de negocio que un sistema debe implementar basadas en conjuntos de condicionesForma general

69



Condiciones de entrada

70



Acciones que se toman conrespecto a valores de las

condiciones

71


Ejemplo

Cada regla se vuelve un caso de pruebasLas condiciones especifican entradasLas acciones especifican resultados esperados

Las condiciones pueden ser más complejasEj: Rangos. Se debe escoger un valor

72


Simplificación de tablas

73


Simplificación de tablas

74


Simplificación de tabasNI – No importaNota: Tener mucho cuidado al colapsar tablas

75


AplicabilidadLas pruebas de tablas de decisión se usan cuando el sistema debe implementar reglas complejas de negocio y cuando estas reglas pueden ser representadas como una combinación de condiciones y que estas condiciones están asocioadas a acciones discretas.

76




77

Pruebas de pares

En algunos casos la cantidad de combinaciones de pruebas es demasiado elevadaEjemplo

8 navegadores3 plug-ins6 sistemas operativos3 servidores3 sistemas operativos del lado servidor1,296 combinaciones

La solución es probar pares de valoresEj. 4 parametros de entrada cada uno con tres valores distintos

Total de combinaciones 3^4 = 81Usando pares sólo requiere 9 pruebas3^13 = 1'594'323 se reduce a 15 pruebas10^20 se reduce a 180 pruebas

78

Pruebas de pares

Dos técnicasArreglos ortogonales y algoritmo allpairs

Arreglos ortogonalesEs un arreglo en el cual si se escogen cualquier par de columnas, todas las combinaciones de pares ocurrirán en las columnasEjemplo: arreglo

9 renglones4 columnasValor max = 3

79

Prueba de pares

Uso de arreglo ortogonal1.- Identificar variables2.- Determinar valores de variables3.- Encontrar un arreglo ortogonal que tenga una columna para cada variable y valores dentro de las columnas que correspondan a las opciones para cada variable4.- Mapear el problema de prueba al arreglo5.- Construir casos de prueba

Búsqueda de arreglosEs difícil encontrar arreglos exactos

Para el problema anterior tendría que ser 8 6 3Catalogo: www.research.att.com/%7Enjas/oadir/index.htmlHay que escoger el siguiente

1 1 3

80

Prueba de pares

Ver ejemplo en libro “Practitioner's guide to software test design”

Algoritmo AllpairsEl algoritmo Allpairs genera las combinaciones de pares

AplicabilidadAl crear y ejecutar entre 1 y 20 % de las pruebas se encuentran entre 70 y 85% de los defectosSe aplica a todos los niveles de pruebaNo garantiza resultados pero no queda más que intentarlo

81



Caja blancaPrueba de flujo de controlPrueba de flujo de datos

82

Prueba de transición de estados

Los diagramas de transición de estados son usados para documentar ciertos tipos de requerimientos así como en el diseño

Son además una herramienta muy útil en la realización de pruebas

Raisedllegar trap RAISE Acknowledged

"reconocer"

Discarded

"descartar" "descartar"

[Sync_]Cleared

llega trap CLEAR

llega trap CLEAR

llega trap CLEAR

[ fecha de aparicion anterior a 30 dias ] / pasa a bitacora

Stored

83

Pruebas de transición de estados

4 niveles de cobertura de pruebas1.- Conjunto de casos de prueba donde cada uno de los estados es visitado al menos una vez

Nivel débil de cobertura


"reconocer"

Discarded


[Sync_]Cleared

llega trap CLEAR

llega trap CLEAR

llega trap CLEAR


Stored

84


4 niveles de cobertura de pruebas2.- Conjunto de casos de prueba donde cada uno de los eventos es disparado al menos una vez

Nivel débil de cobertura


"reconocer"

Discarded


[Sync_]Cleared

llega trap CLEAR

llega trap CLEAR

llega trap CLEAR


Stored

85


4 niveles de cobertura de pruebas3.- Conjunto de casos de prueba donde cada uno de las rutas posibles es recorrida al menos una vez

Cobertura optima pero no siempre realizable (si hay ciclos)


"reconocer"

Discarded


[Sync_]Cleared

llega trap CLEAR

llega trap CLEAR

llega trap CLEAR


Stored

86


4 niveles de cobertura de pruebas4.- Conjunto de casos de prueba donde cada una de las transiciones se ejercita al menos una vez

Buena cobertura sin demasiadas pruebas


"reconocer"

Discarded


[Sync_]Cleared

llega trap CLEAR

llega trap CLEAR

llega trap CLEAR


Stored

87


AplicabilidadCuando el sistema tiene estado

RecomendaciónEjercitar todas las transiciones al menos una vezEn sistemas críticos, ejercitar todos los caminos

88




89

Pruebas de casos de uso

Regla básicaCrear al menos un caso de uso para el flujo principal y al menos uno para cada flujo alternativo y excepcional.

Datos de entradaDado que el caso de uso no los especifica, es necesario definirlosPor ej. Usando técnicas descritas anteriormente

Datos normales, datos de frontera, datos inválidosSi es posible, violar pre-condiciones

90

Pruebas de casos de uso

AplicabilidadSon la piedra angular de las pruebas de sistema y de aceptación

RecomendacionesDe 30 a 40 % del esfuerzo de pruebas de casos de uso (o pruebas de transacción) es absorbido por la generación, captura y extracción de datos de prueba.

No olvidar incluir recursos para este trabajo en la planeación del proyecto

91




92

Pruebas de caja blanca

DefiniciónLas pruebas de caja blanca son una estrategia basada en las rutas internas de ejecución, estructura e implementación de la aplicación bajo pruebas. A diferencia de las pruebas de caja negra, este tipo de pruebas requieren de disponer de habilidades de programación avanzadas.

Ruta: una secuencia de ejecución de instrucciones que comienza en un punto de entrada y culmina en un punto de salida

Proceso1.- Se analiza la implementación de la aplicación2.- Las rutas a través de la aplicación son identificados3.- Se escogen entradas que permitan ejecutar rutas particulares. Se determinan salidas esperadas.4.- Se ejecutan las pruebas5.- Se comparan las salidas con las entradas6.- Se realizan conclusiones sobre el funcionamiento de la aplicación (si es correcto o no)

93


AplicabilidadLas pruebas de caja blanca se pueden aplicar en los niveles unitario, de integración y de sistema

En general, se piensa que las pruebas de caja blanca son iguales a las pruebas unitarias que realizan los desarrolladores.

Aunque esto es correcto es una visión estrecha de este tipo de pruebas.

Las pruebas de caja blanca buscan probar más que el código, las rutas dentro de este.Las rutas pueden probarse dentro de un módulo (prueba unitaria), dentro de subsistemas y dentro del sistema mismo.

Tienen como ventaja que permiten saber que todas las rutas han sido verificadas

94


Desventajas principales1. El número de rutas de ejecución es tan grande que no pueden ser probadas todas.

Esto es tan imposible como probar todas las combinaciones de entrada en pruebas de caja negra

2. Los casos de prueba pueden no detectar errores a nivel de los datos

Ej. y = 2*x (en vez de x^2) funciona para x=0 y x=23.- Las pruebas de caja blanca asumen que el flujo de control es correcto. Dado que las pruebas se basan en rutas existentes, no se pueden descubrir rutas inexistentes.4.- El probador debe tener las habilidades de programación necesarias para comprender y evaluar el software que se está probando.

95




96

Pruebas de control de flujo

PrincipioEste enfoque identifica las rutas de ejecución a través de un módulo y crea y ejecuta casos de pruebas sobre esas rutas

Realizar una prueba exhaustiva de todas las rutas de flujo de control tiene dificultades

El número de rutas puede ser demasiado grande y por lo tanto resulta imposible probarlas todas en un tiempo razonable

97


Cada decisión duplica el número de rutas y cada ciclo multiplica las rutas por el número de iteraciones dentro del ciclo

Por ejemplo:

Tiene mil millones de opciones que podrían probarse

El módulo puede ejecutarse de forma correcta para casi todos los valores, excepto algunos pocos

for (i=1; i

98


Rutas faltantesCualquier enfoque basado únicamente en las rutas que han sido implementadas nunca encontrará aquellas que no lo están

Control de flujo correcto con defectosPueden existir problemas en las instrucciones aún si el control de flujo es correcto

if (a>0) doIsGreater();if (a==0) dolsEqual();// falta - if (a

99


Grafos de flujo de controlLas pruebas de flujo de control se basan en ellos. Los grafos documentan la estructura de control del módulo.

El código es convertido a grafos y los caminos a través de los grafos son analizados. Los casos de prueba son creados a partir de ese análisis.

Elementos de los grafosBloques de procesamientoPuntos de decisiónPuntos de unión

100


Bloques de procesamientoConjuntos de instrucciones con un punto único de entrada y otro de salida. Dentro las instrucciones se ejecutan secuencialmente.

Puntos de decisiónSon puntos donde el flujo de control puede cambiar. La mayor parte de ellos son binarios y se implementan con instrucciones if-then-else. Los puntos con rutas múltiples son implementados usando instrucciones case.

Puntos de uniónUn punto de unión es un punto en el cual varios flujos de control se unen

101


Ejemplo

102


Nivel de coberturaEn las pruebas de control de flujo se definen distintos niveles de cobertura. La cobertura representa el porcentaje de código probado vs. aquel que no lo ha sido.

NivelesCobertura a nivel de instrucción – Ha sido probada y ejecutada cada instrucción ?

Cobertura a nivel de condiciones – Ha sido ejecutado y probado cada punto de decisión ?

Cobertura a nivel de rutas – Ha sido probada ejecutada y probada cada ruta a través de una parte del código ?

103


Cobertura a nivel instrucciónCada instrucción dentro del módulo es ejecutada al menos una vez dentro de las pruebas. A pesar de parecer un objetivo razonable, muchos defectos pueden pasar desapercibidos a este nivel.Ejemplo

Con a = 5 y b=3 se logra, pero no se recorren todas las rutas

La cobertura a nivel de instrucción generalmente no es un nivel aceptable de pruebas

if (a>0) {x=x+1;}if (b==3) {y=0;}

104


Cobertura de condicionesEn este nivel se escriben suficientes casos de prueba de tal forma que cada decisión que tiene una salida cierta o falsa se evalúe al menos una vez.

En el ejemplo se logra con dos casos de prueba(a=2, b=2 y a=4, b=3).

Cabe señalar que la cobertura dedecisiones no garantiza coberturade rutas pero si garantiza coberturade instrucciones

if (a>0) {x=x+1;}if (b==3) {y=0;}

105


Cobertura a nivel de rutasPara módulos sin ciclos, el numero de rutas es en general suficientemente pequeño para que se puedan construir casos de prueba para cada ruta. Para módulos con ciclos, el numero de rutas es enorme y resulta en un problema muy difícil de resolver

if (a>0) {x=x+1;}if (b==3) {y=0;}

106


AplicabilidadLas pruebas de flujo de control son la piedra angular de las pruebas unitarias. Deben ser usadas para todos los módulos cuyo código no puede se probado de forma suficiente a través de revisiones e inspecciones.

LimitacionesSu limitación es que el probador debe tener suficientes habilidades de programación para comprender el código y su flujo de control además de que este tipo de pruebas puede llevar mucho tiempo.

107




108

Pruebas de flujo de datos

PropósitoLas pruebas de flujo de datos son una herramienta poderosa para detectar usos inapropiados de valores de datos debido a errores de codificación

En general, las variables que contienen datos tienen un ciclo de vida bien definido

Definición (d), uso (u) y destrucción (k)Correcto: du, uu, uk, kd Sospechoso: dd, dk, kkError: ku

main() { int x; if (x==42){ ...}}

109


Pruebas estáticasEl diagrama de flujo de control es anotado con información de definición, uso y destrucciónSe siguen distintos recorridos y se buscan patrones duk correctos e incorrectos

LimitacionesNo funcionan bien con arreglosPuede haber combinaciones impropias en caminos que nunca se recorren y por lo tanto no son errores

110


Ejemplo

111


Ejemplo

kill z

use z

use z

112


Pruebas dinámicasDado que las pruebas de flujo de datos se basan en el flujo de control, se asume que este es correcto. El proceso de pruebas de flujo de datos consiste en encontrar suficientes casos de prueba para que

Cada 'define' sea trazado a cada uno de sus 'uses'Cada 'use' sea trazado desde su 'define' correspondiente

Para realizarloEnumerar cada ruta en el moduloPara cada variable crear al menos un caso de prueba para cubrir cada pareja define-use

113


AplicabilidadLas pruebas de flujo de datos extienden las pruebas de flujo de control. Al igual que con las de flujo de control, deben ser usadas para aquellos módulos cuyo código no pueda ser probado de forma suficiente a través de revisiones e inspecciones.

LimitacionesSus limitaciones son que el probador debe tener suficientes habilidades de programación para entender el código, su flujo de control y sus variables. Esta técnica puede requerir mucho tiempo dados todos los módulos rutas y variables que existen en un sistema.

114

Síntesis

Hemos visto múltiples técnicas de pruebasDe caja negraDe caja blanca

Selección de técnica apropiada se basa enRiesgosNivel de revisiónConocimiento de los probadores

115





116

Documentos IEEE 829

117

Especificación de diseño de pruebas

En el modelo IEEE los casos de prueba están descritos en un documento llamado Especificación de Diseño de Pruebas

Contenido de la especificación1.- Identificador2.- Características a ser probadas3.- Refinamiento del enfoque4.- Identificación de pruebas5.- Criterios de éxito / fallo de características

118


1.- IdentificadorNúmero único junto con fecha y versión para control de cambios.

2.- Características a ser probadasEsta sección describe la o las características para las asociadas a los casos de prueba descritos en el documento.

Referirse a sección de plan de pruebas3.- Refinamiento del enfoque

Esta sección debe soportar la sección de enfoque (o estrategia) del plan de pruebas pero entra en mayor detalle

Enfoque: descripción de la manera en que se realizarán las pruebas y explicación de los problemas que tienen un impacto importante en el éxito de las pruebas y finalmente del proyecto.

119


4.- Identificación de pruebasLos identificadores de los casos de pruebas y una descripción corta de los casos de prueba están descritos. No es necesario describir los detalles de los casos de prueba o su ejecución, dado que los casos serán descritos en un documento separado (especificación de casos de pruebas) o en un programa si están automatizadas.

Ej. TC01- Retirar 200 pesos de una cuenta con 1000 pesos

5.- Criterios de éxito / fallo de característicasEn esta sección se establecen los criterios de lo que constituye el éxito o fallo de las pruebas de estas características.

Ej. porcentaje de casos de prueba pasados

120

Documentos IEEE 829

121

Especificación de caso de prueba

Son la parte medular del proceso de pruebasDescriben qué será ejecutado y qué parte del sistema cubren

Existen múltiples maneras de documentarlasTemplete para especificación de caso de pruebas de IEEE 829Hoja de calculoPrueba automátizada

122


Estructura del templete1. Identificador2. Items de prueba3. Especificación de entradas4. Especificación de salidas5. Necesidades del entorno6. Requerimientos especiales del proceso7. Dependencias entre casos de prueba

El estándar IEEE para casos de prueba es muy detallado

Apropiado para sistemas de alto riesgoMenos apropiado para sistemas en constante evolución

123


1. IdentificadorFecha, numero, versión

2. Items de pruebaDescribe elementos necesarios para ejecutar la prueba

Especificaciones de reqs, de diseño, código...3. Especificación de entradas

Entradas requeridas para el caso de pruebas4. Especificación de salidas

Visión del sistema después de ejecutar las pruebas5. Necesidades del entorno

Necesidades particulares como stubs, archivos, etc...6. Requerimientos especiales del proceso

Descripción de procedimientos particulares que se requieran

7. Dependencias entre casos de prueba

124


Uso de hoja de calculo

Esta es una técnica bastante común. Es particularmente valiosa para probadores que construyen muchos casos de prueba pequeños.

125

Documentos IEEE 829

126

Especificación de procedimiento

PropósitoLa especificación del procedimiento de pruebas es una descripción de la manera en que serán ejecutadas las pruebas.

Puede ser descrita de forma manual o como 'script' usando una herramienta'

Puede ejecutar uno o más casos de prueba

En el caso de scripts se recomienda preparar el entorno y al final restaurarlo a su estado inicial

setUp() y tearDown()

127


1.- Identificador2.- Propósito

Propósito del procedimiento y referencia a los casos de prueba a ser ejecutados

3.- Requerimientos especialesDel entorno, de entrenamiento, etc...

4.- Pasos del procedimiento4.1.- Bitácora

Descripción de métodos para registrar los resultados de la ejecución de pruebas y los incidentes observados

4.2.- Puesta en pieSecuencia de acciones necesarias para preparar procedimiento

4.3.- ArranqueAcciones necesarias para arrancar procedimiento

128


4.- Pasos del procedimiento (sigue...)4.4.- Ejecución

Acciones necesarias durante la ejecución4.5.- Medición

Describe la manera en que se realizarán las mediciones4.6.- Suspensión

Acciones necesarias para suspender prueba4.7.- Reinicio

Identifica puntos donde se puede reiniciar y las acciones para lograrlo

4.8.- TerminaciónAcciones necesarias para terminar la ejecución

4.9.- RestauraciónAcciones necesarias para restaurar el entorno

4.10.- ContingenciasAcciones para lidiar con anomalías

129





130

Implementación de pruebas

PropósitoLa implementación de pruebas es el proceso de adquirir datos, desarrollar procedimientos de prueba, preparar el entorno de pruebas y seleccionar e implementar las herramientas que serán usadas para facilitar este proceso

Algunas preguntas que surgen en esta etapaCómo poner en pié entorno de pruebas?Cómo obtener datos de pruebas?Qué procedimientos serán automatizados?Qué herramientas de prueba se usarán?Cómo se verificarán las pruebas?

131

Implementación de pruebas

Entorno de pruebasLa colección de datos, configuración de hardware, gente (probadores), interfaces, sistemas operativos, manuales, instalaciones y otros elementos que definen un nivel particular de pruebas

132

Vez pasada...

133





134

Ejecución de las pruebas

Qué es?La ejecución de las pruebas es el proceso de ejecutar todas o un sub-conjunto de los casos de pruebas y observar los resultados.Aunque la preparación y la planeación de la ejecución de pruebas ocurren a lo largo del ciclo de vida de desarrollo, la ejecución generalmente ocurre durante o al final del ciclo de desarrollo de software (es decir después de la codificación).

Los sub-productos de la ejecución incluyenReportes de incidentesBitácorasEstatus de pruebasResultados

135

Documentos IEEE-829

136

Responsables de ejecución

La responsabilidad depende del nivel de prueba

Se pueden buscar recursos adicionalesAutores de documentación, miembros de soporte técnico, estudiantes...

137

Aspectos diversos

Orden de ejecuciónCriterio de selección

Depende de la calidad del software, recursos disponibles, documentación existente y resultados de análisis de riesgos

RecomendaciónSe recomienda que el conjunto de pruebas de regresión se ejecute desde el principio para identificar áreas problemáticas

Escritura de casos de prueba durante ejecuciónEs probable que durante la ejecución surjan ideas sobre nuevos casos de prueba. Conviene llevar un registro para después documentarlos apropiadamente e incorporalos

Registro de salidasSe deben registrar las salidas del proceso de ejecución de las pruebas

138

Documentos IEEE-829

139

Bitácora de pruebas

PropósitoMantener un registro cronológico de los detalles relevantes sobre la ejecución de casos de prueba

Contenido1. Identificador2. Descripción3. Registro de actividades y eventos

Se debe hacer lo más libre posible para fomentar a la gente a utilizarlo

No debe entrar en detalles sino referenciar otros documentos

140

Bitácora de pruebas

Ejemplo

141

Documentos IEEE-829

142

Reporte de incidentes

Qué son los incidentes ?Pueden ser definidos como cualquier resultado inusual que ocurre a partir de la ejecución de pruebas o de la operación de la aplicación.Después de ser analizados, los incidentes pueden ser categorizados como defectos, mejoras o quedar como incidentes si no tienen consecuencias o fueron resultado del azar

Un defecto (o bug) es un problema en el software que puede potencialmente causar fallos. Un fallo ocurre cuando un defecto impide que el sistema opere de forma adecuada.

El seguimiento de defectos es una actividad importante

El seguimiento involucra el registrar defectos y su estatus

143

Templete IEEE-829Contenido del templete de reporte de incidentes

1. Identificador2. Resumen del incidente3. Descripción del incidente

3.1 Entradas3.2 Resultados esperados3.3 Resultados actuales3.4 Anomalías3.5 Fecha y hora3.6 Paso del procedimiento3.7 Entorno3.8 Intentos de repetición3.9 Probadores3.10 Observadores

4. Impacto5. Investigación6. Métricas7. Disposición

144

Templete IEEE-829

1. IdentificadorNúmero de identificación de acuerdo a los estándares

2. Resumen de incidenteEs la información que relaciona al incidente con el procedimiento o caso de prueba que permitió descubrirlo.Todo incidente debe poder tener una relación con un caso de prueba, lo cual permite repetir la situación.Si no hay caso de prueba para el incidente, pues se descubrió de manera ad-hoc entonces se debe escribir un caso de prueba para el incidente.

145

Templete IEEE-829

3. Descripción3.1 Entradas

Describe las entradas usadas3.2 Resultados esperados

Viene del caso de pruebas3.3 Resultados actuales

Resultados que se encontraron3.4 Anomalías

Diferencia entre datos actuales y esperados y otras informaciones

3.5 Fecha y horaFecha y hora en que ocurrió el incidente

3.6 Paso del procedimientoEn caso de procedimientos complejos, describe el paso en que el incidente ocurrió

146

Templete IEEE-829

3. Descripción (sigue...)3.7 Entorno

Entorno utilizado3.8 Intentos de repetición

Cuántos intentos se hicieron por repetir la prueba?3.9 Probadores

Quién ejecuto la prueba?3.10 Observadores

Quién más está al tanto del incidente?

4. ImpactoSe refiere al impacto sobre el usuario. El usuario o sus representantes deben decidir sobre el impacto del incidente

Ej. Cosmetic, Minor, Major, Critical

147

Templete IEEE-829

5. InvestigaciónEsta sección explica quién encontró el incidente y quienes son los participantes clave en su resolución.

6. MétricasEsta sección puede ser usada para registrar cualquier cantidad de métricas sobre el tipo, ubicación y causa de los incidentes.

7. Disposición (estatus)Esta sección contiene una bitácora del estatus del incidente a través del proceso de control de cambios

148

Documentos IEEE-829

149

Estatus de pruebas y resultados

Uno de los problemas iniciales a los que se enfrenta un administrador de pruebas durante la ejecución es encontrar una manera de dar seguimiento al estatus de las pruebas

Esto está descrito en el plan maestro de pruebas

Medición del estatus de pruebasEjemplo de tabla de reporte

150

Reporte de resumen de pruebas

PropósitoEl propósito de este documento es resumir los resultados de las actividades de prueba y proveer una evaluación basada en los resultados

La evaluación describe la madurez del producto así como documentación sobre anomalías o limitaciones.

Debe haber un reporte correspondiente a cada plan

Se debe hacer el esfuerzo de realizar este reporte a pesar de que es de las últimas actividades

151


Estructura1. Identificador2. Resumen3. Variaciones4. Evaluación (assessment) comprensiva5. Resumen de resultados

5.1 Incidentes resueltos5.2 Incidentes no resueltos

6. Evaluación7. Recomendaciones8. Resumen de actividades9. Aprobaciones

152


Estructura1. Identificador2. Resumen

Esta sección resume qué actividades se llevaron a cabo, incluyendo versiones del software, entorno, etc... Hace referencia al plan de pruebas, especificaciones de diseño de pruebas, procedimientos y casos de pruebas

3. VariacionesEsta sección describe variaciones entre las pruebas planeadas y aquellas que se realizaron.

4. Evaluación (assessment) comprensivaEn esta sección se evalúa el proceso de pruebas con respecto a los criterios definidos en el plan. Las características que no se cubrieron adecuadamente deben ser mencionadas aquí.

153


Estructura5. Resumen de resultados

Esta sección debe contener métricas sobre los defectos y su distribución5.1 Incidentes resueltos – Identifica todos los incidentes que fueron resueltos y resume la resolución5.2 Incidentes no resueltos – Identifica todos los incidentes no-resueltos

6. EvaluaciónEvaluación de cada item con respecto a los criterios de aceptación o rechazo

7. RecomendacionesRecomendaciones realizadas por el probador

8. Resumen de actividadesResumen de actividades y consumo de recursos para facilitar futuras estimaciones

9. Aprobaciones

154

Terminación de las pruebas

Cómo saber cuando se terminó?Normalmente esto está descrito en el criterio de salida para cada nivel.

Liberar muy temprano o muy tardeUna liberación temprana puede traer múltiples problemas

Muchos defectos en el productoFrustración del cliente

Una liberación tardía puede ser benéfica en algunas áreas pero negativa en otras

Equipo tiene confianza sobre productoPerdida de ganancias

155

Tasa de descubrimiento de errores

Una métrica útilMuchas organizaciones usan esta tasa cómo métrica para asistirlos en predecir cuándo está un producto listo para ser liberado. Cuando la tasa de descubrimiento cae debajo de un nivel especificado, se asume que el proyecto está listo para ser liberado.Se debe tener cuidado de que esta métrica puede estar influenciada por otras situaciones (menor esfuerzo, no hay casos de prueba nuevos, etc...)

Es buena idea basar las decisiones en más de una métrica de soporte (por ejemplo severidad de nuevos defectos descubiertos)

156

Tasa de descubrimiento de errores

Conforme avanza el tiempo, la cantidad de defectos descubiertos disminuye y el costo aumenta

En cierto punto el costo de proseguir las pruebas excede el valor de realizar más pruebas

157

Otros criterios de terminación

Criterios de estimaciónUn criterio para detener las pruebas es basar la decisión en el número de defectos esperados. Esto requiere que se haya colectado información a partir de proyectos anteriores.

Falta de recursosQuedarse sin tiempo o recursos puede ser una razón válida para detenerse. No olvidar que no se aspira por algo perfecto sino por riesgos aceptables. El riesgo de no liberar puede exceder el riesgo de liberar un producto con errores.

158





159

Midiendo la efectividad de las pruebas

La mayor parte de las organizaciones no intentar realizar mediciones de efectividad de pruebas de forma consciente

Todas las métricas de efectividad de pruebas tienen deficiencias

A pesar de lo difícil que es realizar estas mediciones, es necesario desarrollar un conjunto de métricas en la organización

“Cualquier cosa que se necesita cuantificar puede ser medida de una forma superior a no medirlo en lo absoluto”

160

Categorías de métricas

Tres categorías principalesMedidas de satisfacción de clientesMedidas sobre defectosMedidas de cobertura

161

Medidas de satisfacción de clientes

Muchas compañías usan métricas de satisfacción de los clientes con respecto al software

CuestionariosAnálisis de llamadas telefónicas

CuestionariosSon difíciles de realizar.

La inefectividad del cuestionario puede anular la medición

Llamadas telefónicasCantidad de llamadas telefónicas

Se debe analizar cada llamada

Estas métricas, aunque útiles, no permiten medir la efectividad de las pruebas de forma adecuada

162

Análisis de defectos

Cantidad de defectos encontrados durante pruebasEl problema con esta métrica es que un software de mala calidad resultará en una cantidad alta de defectos encontrados durante pruebas mientras que uno de mejor calidad dará menos resultados, lo cual dificulta la medición de la efectividad de las pruebas

Defectos en producciónUna métrica común es la cantidad de defectos encontrados por los clientes. Esta métrica también se ve afectada por la calidad del software y es necesario llevar reportes de severidad, distribución y tendencias a través de cada release

163


Eficiencia de eliminación de defectos (DRE)Es una métrica más poderosa (y recomendada) que se obtiene a partir de las métricas anteriores: defectos encontrados durante las pruebas y durante la producción.Fórmula:

Los defectos no encontrados provienen de los clientesSe debe tomar en cuenta la severidad de los defectos

La eficiencia de eliminación de defectos es un porcentaje

Idealmente se aproxima de 100 %Se reportan rangos entre 65 – 70%

Defectos encontrados en pruebasDefectos encontrados en pruebas + no encontradosDRE =

164


Edad de los defectosEntre más tarde se encuentra un defecto, más cuesta repararloLa tabla siguiente muestra el “peso” que tiene el encontrar un defecto en cierto punto de del desarrollo, relativo al momento en que el defecto fue creado

165


EjemploCantidad de defectos encontrados

En este ejemplo, se encontraron 8 defectos de requerimientos en la fase de diseño de alto nivel

166


Decaimiento (spoilage)Es una métrica que usa el peso de los defectos y su distribución para medir la efectividad de las actividades de retiro de defectos.

El valor óptimo es 1, pero su esta medida cobra realmente sentido cuando se evalúan tendencias

Σ (Num. Defectos * Peso)Total de defectosDecaimiento =

167


Densidad de defectos y análisis de pareto

Es necesario definirQué se cuenta como defecto ?Cómo se cuentan las líneas de código ?

Representación gráfica

Numero de DefectosLíneas de código o puntos de funciónDensidad =

168






En general, los módulos con alta concentración de defectos descubiertos presentan mayor

riesgo pues tienen a seguir teniendo defectos

169






Análisis de pareto: Pocos factores causan la mayoría de los problemas. Al ordenar en

forma decreciente se puede ver donde cuales son esos

factores.

170


Métricas de coberturaEste tipo de métricas son probablemente las más poderosas para medir la efectividad de las pruebas puesto que no se realizan “a posteriori” y no se ven afectadas por la calidad del software que se está probando.

Cobertura de alto nivelMétricas de cobertura de alto nivel pueden ser realizadas en cuanto se definen los casos de prueba, sin necesidad de escribir código.

Matriz de cobertura

171


Cobertura de códigoEj. usando “cobertura”

Tener un alto porcentaje de cobertura no garantiza que las pruebas son buenas

172





173

Mejora del proceso de pruebas

8 Etapas1. Establecer línea de base de prácticas actuales2. Desarrollar visión y objetivos3. Formular y priorizar requerimientos4. Establecer un proyecto5. Desarrollar un plan6. Introducir cambio de manera incremental7. Medir resultados8. Regresar a paso 1

174


1. Establecer línea de base de prácticas actualesLa primera etapa para mejorar el proceso de prueba es establecer una línea de base de las prácticas actuales. Esto permite tener un punto de comparación para medir el éxito del proceso de mejora.

2. Desarrollar visión y objetivos“Si no se sabe a donde se va, todos los caminos son buenos”El complemento de la línea de base es una visión de donde se quiere estar en el futuro. Es difícil establecer una visión clara desde el principio, así que la visión requiere de actualización constante.Tener una frase de visión y objetivos muy concretos

En vez de las típicas frases de visión vagas

175


3. Formular y priorizar requerimientosLa línea de base establece la situación actual de la organización, y la visión describe el estado final. Enseguida se deben desarrollar los requerimientos para ir de un punto al otro.Los requerimientos deben seguir las reglas básicas de los requerimientos de software

Específicos, medibles, logrables, realistas y a tiempo.Deben soportar la visión y los objetivos

4. Establecer un proyectoLa mejora de procesos no es algo que se pueda hacer en el 'tiempo libre'Una manera de lograrlo es establecer un proyecto

Se establece un equipo, un presupuesto y se realiza un planEn caso de que sea un equipo pequeño, se debe dedicar tiempo específico a esta tarea, aún si es parcial.

176


5. Desarrollar un planSe puede usar un templete como el siguiente

1. Identificador2. Introducción3. Riesgos de planeación4. Estrategia5. Criterios de éxito / fallo6. Criterios de suspensión7. Entregables8. Necesidades del entorno9. Necesidades de equipo y entrenamiento10. Responsabilidades11. Calendario12. Aprobaciones

177


6. Introducir cambio de manera incrementalNo se deben introducir todos los cambios simultáneamente, los cambios se pueden dividir en

Cambios adaptativos – ajustes ligeros sobre lo existenteCambios innovadores – ajustes más importantesCambios radicalmente innovadores – cambios totales

7. Medir resultadosEs necesario comparar los resultados con la iniciativa de los criterios de éxito / falla establecidos en el plan. Esto permitirá saber si se cubrieron los requerimientos especificados en 3.

8. Regresar a paso 1

calidad en el proceso de software:...

Documents