-
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
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
-
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
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
-
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
Pruebas de aceptación
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
Pruebas de aceptación
Trazabilidad de requerimientosAsegura que uno o más casos de prueba cubren cada requerimiento
-
33
Pruebas de aceptación
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
Pruebas de aceptación
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
Pruebas de integración
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
Pruebas de integración
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
Pruebas de integración
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
Pruebas de integración
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
Proceso para diseño de pruebas
6.- Crear una matriz de seguimiento de inventarioEn las columnas se ponen casos de prueba existentes
-
56
Proceso para diseño de pruebas
7.- Identificar pruebas para áreas no cubiertasModificar casos de prueba existentesAgregar casos de prueba nuevos
-
57
Proceso para diseño de pruebas
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
Prueba de equivalencia de clase
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
Prueba de equivalencia de clase
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
Prueba de equivalencia de clase
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
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
-
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
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
-
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
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
Condiciones de entrada
-
70
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
Acciones que se toman conrespecto a valores de las
condiciones
-
71
Pruebas de tablas de decisión
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
Pruebas de tablas de decisión
Simplificación de tablas
-
73
Pruebas de tablas de decisión
Simplificación de tablas
-
74
Pruebas de tablas de decisión
Simplificación de tabasNI – No importaNota: Tener mucho cuidado al colapsar tablas
-
75
Pruebas de tablas de decisión
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
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
-
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
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 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
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
-
84
Pruebas de transición de estados
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
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
-
85
Pruebas de transición de estados
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)
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
-
86
Pruebas de transición de estados
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
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
-
87
Pruebas de transición de estados
AplicabilidadCuando el sistema tiene estado
RecomendaciónEjercitar todas las transiciones al menos una vezEn sistemas críticos, ejercitar todos los caminos
-
88
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 flujo de controlPrueba de flujo de datos
-
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
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 flujo de controlPrueba de flujo de datos
-
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
Pruebas de caja blanca
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
Pruebas de caja blanca
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
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 flujo de controlPrueba de flujo de datos
-
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
Pruebas de control de flujo
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
Pruebas de control de flujo
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
Pruebas de control de flujo
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
Pruebas de control de flujo
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
Pruebas de control de flujo
Ejemplo
-
102
Pruebas de control de flujo
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
Pruebas de control de flujo
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
Pruebas de control de flujo
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
Pruebas de control de flujo
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
Pruebas de control de flujo
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
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 flujo de controlPrueba de flujo de datos
-
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 de flujo de datos
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
Pruebas de flujo de datos
Ejemplo
-
111
Pruebas de flujo de datos
Ejemplo
kill z
use z
use z
-
112
Pruebas de flujo de datos
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
Pruebas de flujo de datos
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
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
-
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
Especificación de diseño de pruebas
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
Especificación de diseño de pruebas
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
Especificación de caso de prueba
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
Especificación de caso de prueba
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
Especificación de caso de prueba
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
Especificación de procedimiento
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
Especificación de procedimiento
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
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
-
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
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
-
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
Reporte de resumen de pruebas
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
Reporte de resumen de pruebas
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
Reporte de resumen de pruebas
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
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
-
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
Análisis de defectos
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
Análisis de defectos
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
Análisis de defectos
EjemploCantidad de defectos encontrados
En este ejemplo, se encontraron 8 defectos de requerimientos en la fase de diseño de alto nivel
-
166
Análisis de defectos
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
Análisis de defectos
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
Análisis de defectos
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 =
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 defectos
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 =
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
Análisis de defectos
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
Análisis de defectos
Cobertura de códigoEj. usando “cobertura”
Tener un alto porcentaje de cobertura no garantiza que las pruebas son buenas
-
172
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
-
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
Mejora del proceso de pruebas
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
Mejora del proceso de pruebas
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
Mejora del proceso de pruebas
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
Mejora del proceso de pruebas
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