Fundamentos de pruebas

Proceso de pruebas

Planificación y control

Selección de condiciones de

prueba

Diseño y ejecución de casos de prueba

Comprobación de resultados

Generación de informes

Actividades de cierre

Depuración

PruebaDetección –

Identificación de defectos

Corrección de defectos

Repetición de Pruebas

Siete principios del proceso de pruebas

1. El proceso demuestra la presencia de defectos, no la ausencia de ellos2. No hay pruebas exhaustivas3. Pruebas tempranas (detección de defectos)4. Agrupamiento de defectos (hongos/cucarachas5. Paradoja del pesticida (revisar/modificar pruebas)6. Las pruebas dependen del concepto (entorno de prueba Vs. Entorno de producción)7. La falacia de la ausencia de errores

Psicología del proceso de prueba

Desarrollador

Tester

Diseñar desarrollar probar

Objetivo común

Aportar un buen producto

Código ético

PúblicoCliente / empleadorProductoJuicioGestiónProfesiónCompañeros de profesiónIndividualmente

Modelo W

Definición de requisitos

Diseño funcional del sistema

Diseño técnico del sistema

Especificación de componentes

Programación

Pruebas de componente

Pruebas de integración

Pruebas de sistema

Pruebas de aceptación

Modelos de desarrollo de Software

VerificaciónVs.

Validación

Comprobación de la conformidad con los requisitos }construcción del sistema

Comprobación de la idoneidad para el uso esperado Sistema correcto

Modelo V

Requisitos funcionales

Diseño funcional del sistema

Diseño funcional técnico

Especificación de componentes

Programación

Pruebas de componente

Pruebas de integración

Pruebas de sistema

Pruebas de aceptación

Planificar actividades de pruebas

Planificar prueba del sistema

Planificar prueba de integración

Planificar prueba de componentes

Ejecución de prueba de componentes

Ejecución de prueba de integración

Ejecución de prueba de sistema

Ejecución de prueba de aceptación

Ciertas actividades de aseguramiento de calidad se desarrollan en paralelo al proceso de desarrollo

Modelos iterativos

Las actividades se realizan de forma

continua

Factores de relevancia

Pruebas de regresión

Automatización de pruebas

Modelo prototipado Desarrollo de una representación del sistema seguida de modificaciones sucesivas hasta que sea finalizado

Desarrollo rápido de aplicaciones La interfaz de usuario se implementa utilizando una funcionalidad ya construida simulando otra posteriormente desarrollada

Proceso unificado Modelo orientado a objetos. Aporta el lenguaje de modelado UML y soporte al proceso unificado

Programación extrema Desarrollo y pruebas tienen lugar sin una especificación de requisitos

Desarrollo guiado por pruebas

•Preparación de versiones de componentes para su prueba•Ejecución automática de pruebas•Corrección de defectos•Repetición de pruebas hasta no encontrar defectos

Principios de todos los modelos

•Cada actividad de desarrollo debe ser probada•Cada nivel de prueba debe ser probado de forma especifica•El proceso de pruebas comienza antes de la ejecución de las mismas

Programación

Pruebas de componente

Pruebas de integración

Pruebas de sistema

Pruebas de aceptación

•También llamadas pruebas unitarias•Se hace referencia a un componente como

•Prueba de módulo (module test en C)•Pruebas de clase (class test en Java ó C++)•Pruebas de unidad (unit test Pascal)

•También denominadas pruebas de desarrollador•Alcance componentes individuales probados de forma independiente•Defectos encontrados: en procesamiento de datos, valores límite, funciones ausentes•Puede probar atributos no funcionales•Requiere controladores (drivers) que simulan datos de entrada, registran datos de salida y aportan un área de pruebas•Utiliza un stub•Se deben tener conocimientos de programación

Programación

Pruebas de componente

Pruebas de integración

Pruebas de sistema

Pruebas de aceptación

•Comprueban funciones externas•Comprueba interacción entre elementos de software, entre distintos sistemas o entre hardware y Software•Pueden ser ejecutados por desarrolladores y probadores•Comprueban las interfaces con el entorno del sistema•Son necesarios controladores de prueba que pueden ser reutilizados•Herramientas de control•Los stubs reemplazan componentes ausentes•Al reemplazar drivers y stubs por componentes reales se pueden perder datos, interpretación errónea de datos, datos transferidos en momentos incorrectos•Usa enfoque incremental y estrategias ascendente y descendente•Integración ad-hoc realizadas inmediatamente terminada su construcción

Programación

Pruebas de componente

Pruebas de integración

Pruebas de sistema

Pruebas de aceptación

•Comportamiento del sistema completo•Se refiere a requisitos funcionales y no funcionales•El entorno de pruebas debe coincidir con el real•No se realizan pruebas en el entorno real•Las características a ser probadas incluyen: adecuación, exactitud, interoperabilidad, seguridad y cumplimiento de funcionalidad•Requisitos funcionales: pruebas basadas en procesos de negocio, en casos de uso, en requisitos•Requisitos no funcionales: no son establecidos de forma explícita, difíciles de cuantificar

Programación

Pruebas de componente

Pruebas de integración

Pruebas de sistema

Pruebas de aceptación

•Deben tener en cuenta normas y reglamentos gubernamentales, legales, industriales y de otro tipo•Se verifica la adecuación del uso al sistema por parte de usuarios de negocio•Las pruebas se realizan utilizando el entorno del cliente•Requiere que el Software sea adecuado para producción: integración del Software y las TI del cliente, gestión de usuarios, compatibilidad con otros sistemas, tareas de mantenimiento, de carga y migración de datos, comprobaciones periódicas de vulnerabilidad de la seguridad•Pruebas alpha y beta: es necesaria una versión preliminar y estable del software, pruebas realizadas en COTS, aporta feedback

•Dependencias del desarrolladorAlpha

•Dependencias del cliente Beta

Se aplican distintos tipos de pruebas durante las distintos niveles anteriores

Tipos de pruebas Objetivo Ámbito de la aplicación Ejecución

Funcionales Probar función (métodos de caja negra)

Todos los niveles de prueba •Utilizan datos derivados de los casos de prueba•Pruebas de seguridad•Aborda amenazas externas•Ataques pueden dañar programas o datos

No funcionales Características del producto SW ( las características de calidad a menudo son vagas y dificultan las pruebas)

•Todos los niveles de pruebas•Pruebas no funcionales típicas:

•De carga•De rendimiento•De volumen•De estrés•De las características de seguridad•De fiabilidad•De robustez•De usabilidad

•La conformidad con los requisitos no funcionales se miden utilizando requisitos funcionales seleccionados

De la estructura SW Cobertura (enfoque: caja blanca) •Todos los niveles de prueba conjunta a las pruebas de componente y de integración

•Se probará la estructura interna de un objeto de prueba•Todos los elementos deben estar cubiertos por casos de prueba

Pruebas asociadas al cambio Probar objeto después de los cambios

•Repetir una prueba (prueba de regresión)•Análisis de impacto•Las pruebas de confirmación/regresión pueden ser realizadas en todos los niveles•Pruebas típicas después de un cambio:

•Repetición de prueba•Pruebas de regresión

•La misma forma en la cual se han ejecutado en iteraciones previas•Si durante fases tempranas es evidente ciertas pruebas de regresión se debe considerar la automatización

Pruebas posteriores a la aceptación del producto

Alcance:•Análisis de impacto•Documentación completa

•Configuración•Análisis de impacto•Pruebas de mantenimiento Mantenimiento: Corrección de errores

Distribuciones de SW planificados: adaptaciones como resultado de una modificación / cambio

•Retirada del SW Pruebas de migración de datosVerificación del archivo de datos y programasPruebas en paralelo de sistemas nuevo y su antecedente

Técnicas estáticas

Pueden detectar defectos que no son detectables en las pruebas dinámicas

Revisiones (manual)Análisis estático (herramientas)

La detección temprana de errores ahorra costes

Revisiones

Ventajas Desventajas

•(-) costes (+) potencial de ahorro•Defectos detectados y corregidos de forma temprana•Documentos de alta calidad mejoran desarrollo•Mejora el “know-How”

•Tensión en caso de enfrentamientos con el producto•Los expertos necesitan una buena preparación con el producto•Inversión considerable del tiempo•Moderador y participantes influyen en la calidad del producto

Revisión Formal

•Planificación Definición de los criteriosSelección de personalAsignación de roles y tiempos

•Definición de criterios de entrada / salida Dependiendo de la importancia y complejidad

•Inicio (Kick-off) Distribución de documentosExplicación de Objetivos

ProcesoDocumentos

•Comprobación de los criterios de entrada

•Preparación individual Inspección de objetos, identificar los que requieren aclaración

•Identificación Defectos potencialesPreguntasComentarios

•Reunión de revisión Presentación de resultadosDiscusión con resultadosDefectos Identificación

Presentación de recomendacionesToma de decisiones

•Examen / evaluación / registro

•Reconstrucción Corrección de defectosSegunda reunión

•Comprobación de los criterios de salida

Roles y responsabilidades

Jefe de proyecto(manager)

•Inicia revisión•Asigna tiempos•Determina si se han alcanzado objetivos

Moderador(Moderator)

•Dirige la reunión / concluye resultados•Planificación / ejecución de la revisión y seguimiento•En él recae el éxito de la revisión

Autor(Author)

•Redactor o responsable del objeto de revisión•Expone trabajo a la crítica•Hace los cambios recomendados

Revisor(Reviewer)

•Conoce sobre: negocio o técnico•Detecta: defectos, desviaciones, áreas problemáticas

Escriba(Scribe)

•Documenta

Lista de comprobación(checklist)

•Identificar audiencia•Crear logo•Crear / optimizar Sitio Web•Definir requisitos•Configurar orden del sitio•Crear lista de beneficios•Métricas

Tipos de revisiones

Inspección •Dirigida por moderador•Celebrado como un examen•Funciones definidas•Recopilación de métricas•Basados en normas y listas de comprobación•Criterios de entrada y salida para la aprobación del producto•Preparación previa de la reunión•Lista de conclusiones•Seguimiento formal•Lector opcional•Identificar defectos

Guiada •Liderado por el autor•Puede adoptar forma de escenarios, simulacros o participación del grupo de pares•Sesiones abiertas•Varía desde formal hasta informal•Objetivos: aprender, entender y encontrar defectos

Técnica •Progreso documentado y definido•Preparación previa•Dirigida por un moderador•Elaboración de un reporte•Varía desde formal hasta informal•Objetivos: debatir, tomar decisiones, encontrar defectos, evaluar alternativas, etc

Informal •Ausencia de proceso formal•Puede adoptar diferentes formas dependiendo de los diseños y el código•Los resultados pueden estar o no documentados•La utilidad varía en función de los revisores•Forma barata de obtener beneficios

Factores de éxito

•Orientadas al logro de objetivos•Hablar al autor de una forma positiva•Uso sistemático de técnicas y plantillas•Uso del presupuesto apropiado•Utilizar retroalimentación para mejora continua•Crear ambiente de confianza•Involucrar a la gente adecuada

Análisis estático con herramientas

•Reglas y estándares•Diseño de un programa (flujo de control)•Uso de datos (Flujo de datos)•Complejidad de la estructura de un programa•Métrica

Aspectos que comprueba

Consiste en analizar un objeto de prueba sin ejecutarlo

Debe tener una estructura formal

Valor del análisis estático

•Encontrar defectos•Advertir sobre aspectos sospechosos del código•Detectar discrepancias en el diseño•Comprobar mantenibilidad del código o del diseño

Prevención

Herramientas Compilador detectar errores sintácticos / crea datos de referencia / comprueba consistencia entre variablesAnalizador convenciones y estándares / métricas de complejidad / acoplamiento de objetos

Análisis Propósito Método Resultados

Del flujo de control •Detectar defectos causados por un desarrollo anómalo del código

•La estructura del código se muestra como un diagrama de control de flujo•Grafo dirigido:

•Los nodos representan sentencias o secuencias de sentencias•Las aristas representan la transferencia del flujo de control (decisiones y bucles)•Construcción mediante herramientas

•Visión del código del programa•Las anomalías pueden detectarse fácilmente:

•Bucles abandonados•Ramas muertas•Retornos múltiples

Grafo de flujo de control = diagrama de flujo simplificado

Del flujo de datos •Detección de anomalías en el flujo de datos

Beneficios: •Detección fiable de anomalías en flujo de datos•Se puede detectar fácilmente la localización de defectos•Buen complemento para otros métodos de prueba

Desventajas:•Limitado a un rango reducido de tipos de defectos

Las métricas Tamaño del programaEstructura de control del programaEstructuras de control de datos

Número ciclomático [v(G)]

Si es > 10 necesita ser reconstruido

Métrica que mide la complejidad estática de un programa basado en su grafo de flujo de controlMide caminos linealmente independientes (testabilidad y mantenibilidad)

V(G) = e – n + 2pe= # aristasn= nodosp= partes del programa independientes inspeccionadas

Proceso de desarrollo de pruebas

ControladoCreados formal o informalmenteTrazabilidad ayuda a determinar la cobertura de requisitos

Objeto de prueba: elemento a ser revisadoCondición de prueba: elemento o eventoCriterios de prueba: el objeto debe cubrirlos con el fin de superar la pruebaCalendario de ejecución de prueba: los procedimientos están incluidos, en sus contextos y en el orden que deben ser ejecutados

Descripción de un caso de prueba [IEEE 829]

•Precondiciones: situaciones previas antes de llevar a cabo la ejecución•Valores de entrada: descripción de los datos de entrada de un objeto de prueba•Resultados esperados: datos de salida que se esperan •Poscondiciones: descripción de un objeto tras ejecución•Dependencias: orden de ejecución de los casos de prueba•Identificador distinguible: código con el fin de identificar •Requisitos: características del objeto de prueba que se evaluarán

Combinación de casos de prueba

Juegos de prueba especificación de procedimiento de pruebas / scripts / herramientas / plan de prueba (secuencia quien / cuando)Escenarios de pruebas

Pruebas de caja negra = prueba funcional orientada a la especificaciónPruebas de caja blanca = prueba basada en la estructura o prueba basada en el flujo de control

Categorías de las técnicas de diseño de pruebas

•Métodos basados en las especificación•Objeto de prueba seleccionado de acuerdo al modelo funcional•La cobertura de la especificación puede ser medida

•Métodos basados en la estructura•La estructura interna es la utilizada para diseñar casos de prueba•El % de cobertura es medido y utilizado para la creación de pruebas adicionales

•Método basados en la experiencia•Conocimiento y experiencia son base para el diseño de casos de prueba•Conocimiento y experiencia de puntos débiles, errores y posibles errores son usados para determinar / definir casos de prueba

Métodos de caja negra

•Partición equivalente / segmentación de equivalencia / clase de equivalencia (CE)•Dividen los posibles valores en clases

•Valores entrada / salida•Rango de valores agrupado en clases de equivalencia.

•Reglas:•Valores con comportamiento común se agrupan en CE•No pueden superponerse y no presentan discontinuidad•Pueden constituir en un rango de valores o en un valor aislado

•Valida: todos los valores dentro del rango•No valida: valores fuera del rango. Hay 2 casos

•Valores con forma correcta se pueden combinar en 1 ó más clases de CE•Valores con formato incorrecto que forman parte de una CE separada

•La calidad de la prueba depende de la segmentación precisa de variables / elementos en clases de equivalencia

# de CE probados# de CE definidos

•Transición de la especificación = definición de la funcionalidad a la creación de las clases de equivalencia•Beneficios:

•Con una cantidad mínima de casos de prueba se puede esperar un valor de cobertura•Utilizada para lograr objetivos de cobertura de entrada y salidas•La asignación de prioridades a la clase de equivalencia puede ser utilizada para la asignación de prioridades a los casos de prueba

•Análisis de valores límite•Amplía la técnica de CE introduciendo una regla para seleccionar representantes•Cuando los valores son un único valor numérico se toma en cuenta la clase y su entorno como representantes

•Tablas de decisión & gráfico causa-efecto•El conjunto completo de combinaciones conduce a un número muy alto de casos de prueba•El gráfico causa-efecto utiliza un lenguaje formal•Elementos:

•Aseveración

•Negación

•O

•Y

•Exclusivo

•Inclusivo

•Uno y sólo uno

•Requerido

•Beneficios: identificación sistemática de combinaciones de entrada; el número de casos de prueba se puede reducir por la fusión sistemática de columnas•Desventajas: añadir gran número de causas conduce a resultados complejos; se puede incurrir en errores; requiere uso de herramientas

•Pruebas de transición de estado•No se tiene en cuenta los diferentes estados que puede tomar el objeto de prueba•Se utilizan en la industria del SW embebido u automatización técnica general•Se debe construir un árbol de transición

•Cada camino desde la raíz a una hoja representa un caso de prueba de transición de estado

Cobertura (CE)= ------------------------------- * 100%

A E

A E~

BA

E

^

BA

E^

BA

Ex

BA

I

BA

O

BA

R

Métodos de caja negra

•Beneficios y desventajas•Buen método de prueba•Buen método si el ciclo de vida del objeto está disponible•Muchas veces los estados son complejos•Sólo cubriendo todos los estados se garantiza la prueba

•Pruebas basadas en casos de uso•El objeto de prueba es visto como un sistema reaccionando con actores•Todo caso de uso tiene precondiciones y poscondiciones•Son elementos del Lenguaje Unificado de Modelado (UML)•Describe un comportamiento, no una secuencia de eventos•Muestra la reacción del sistema desde el punto de vista del usuario•Cada caso de uso puede ser utilizado como fuente para un caso de prueba•Un caso de uso puede ser utilizado como fuente para un caso de prueba•Un caso de uso incluye: precondiciones / resultados esperados / comportamiento del sistema / poscondiciones•Beneficios:

•Apropiadas para pruebas de aceptación y de sistema•Pueden ser combinadas con otras técnicas de prueba

•Desventajas•Nula obtención de casos de prueba más allá de la información aportada•Debe ser utilizada en combinación con otros métodos

Métodos de caja Blanca

Técnicas basadas en la estructura del SW o del sistema

Nivel de componenteNivel de integraciónNivel de sistema

Requieren uso de herramientas

•Cobertura de sentencia•La atención se centra en la sentencia del código de un programa•La base es el gráfico de flujo de control•Su objetivo es lograr la cobertura de un porcentaje de las sentencias

# de sentencias ejecutadas # total de sentencias

•Beneficios / desventajas•Será detectado el código muerto no logrando una cobertura del 100%•No se detectarán instrucciones faltantes

•Cobertura de decisión•Se centra en el flujo de control•Su objetivo es lograr la cobertura de un porcentaje específico de todas las decisiones

# de decisiones ejecutadas # total de decisiones

# de ramas cubiertas # total de ramas

•Pruebas de sentencia y cobertura y pruebas de decisión y cobertura•Solo se considera el resultado final de una condición•Tiene por objetivo detectar defectos que resulten de la implementación de condiciones múltiples•Hay 3 tipos de cobertura de condición

•Cobertura de condición simpleCada sub-condición debe tomar al menos una vez los valores lógicos verdaderos

•Cobertura de condición múltipleTodas las combinaciones que puedan ser creadas utilizando permutaciones de las subcondiciones

•Mínima cobertura de condición múltipleTodas las condiciones que puedan ser creadas utilizando los resultados lógicos de cada subcondición deben ser parte de las pruebas

Cobertura de sentencia (CO)= --------------------------------------- * 100%

Cobertura de decisión (C1)= --------------------------------------- * 100%

Cobertura de sentencia (C1)= -------------------------------- * 100%

•Prueba de camino y cobertura•Ejecución de todos los posibles caminos a través de un programa•Alto número de casos de prueba•El foco del análisis es el gráfico de flujo de control•El objetivo de esta prueba es alcanzar un porcentaje definido de cobertura

# de caminos cubiertos # total de caminos

•La cobertura de camino es más exhaustiva que la cobertura de sentencia y de decisión•100% de cobertura de camino incluye 00% de cobertura de decisión que a su vez incluye 100% de cobertura de sentencia

Cobertura de camino = ----------------------------------- * 100%

Métodos de caja Blanca

Técnicas basadas en la experiencia o intuitivas

•Los casos de prueba están basados en la intuición y en la experiencia•Para completar otros métodos más formales•Produce casos de prueba adicionales•Posibles fuentes

•Resultados de prueba y experiencia en sistemas similares•Experiencia de usuario•Enfoque del despliegue•Problemas de desarrollo

•Predicción de errores•Comprobar lista de defectos•Diseño de caso de prueba•Actualizar lista de defectos durante las pruebas

Pruebas exploratorias

Cuando la información base se encuentra poco estructurada

•Revisar partes constituyentes•Ejecutar número reducido de casos de prueba•Analizar resultados•Iteración•Concentrarse en áreas relevantes y explotando características adicionales•Tomar en cuenta las herramientas•Seleccionar objetos pequeños y concentrarse en aspectos particulares •Modelado durante el proceso de pruebas•Preparación de pruebas adicionales

***A través de las pruebas intuitivas se pueden detectar defectos que no son detectados a través de métodos sistemáticos

Diseño de casos de prueba (selección)

•Estado de la información respecto del objeto de prueba•Objetivos de prueba predominantes•Riesgos•Precondiciones del proyecto•Características del objeto de prueba•Requisitos contractuales del cliente•Buena práctica•Niveles de prueba

Intereses en el diseño de prueba

•Jefe del proyecto•Desarrollador SW de alta calidad•Cumple con las restricciones de tiempo y presupuesto

•Cliente / iniciador del proyecto•Recibir SW de calidad•Cumplir con las restricciones de tiempo y presupuesto

•Jefe de prueba•Pruebas suficientes e intensivas / técnicas necesarias•Evaluar / valorar nivel de calidad•Asignar y utilizar recursos para las pruebas

Gestión de pruebas

•Es necesaria a lo largo de todo el proceso

•Ventajas•Imparcialidad•Se pueden cuestionar las bases de prueba y verificar suposiciones hechas durante el diseño de pruebas

•Desventajas•Aumenta esfuerzo dedicado en la comunicación •Los desarrolladores pierden sentido de responsabilidad

Actividad Producto resultado del trabajo

Concepción de pruebas Plan de pruebas (estático)

Planificación de pruebas Plan de pruebas (dinámico)

Control de pruebas Informe de estado, acción de control

Pruebas de aceptación Entrega (release) del producto SW

Perfiles del personal de prueba

Perfil Características Competencias

Jefe de pruebas o gestor de pruebas o coordinador de pruebas

•Planifica, realiza el seguimiento y control del proyecto de pruebas

•Gestión de pruebas y calidad del SW•Planificación y control de pruebas•Experiencia como jefe de pruebas•Habilidades de gestor

Diseñador de pruebas •Diseña los casos de prueba y establece orden de la ejecución

•Conocimiento y desarrollo de pruebas•Conocimiento de ingenieros de SW•Conocimientos de especificaciones técnicas•Conocimientos de requisitos funcionales

Ingeniero de automatización de pruebas •Evalúa las posibilidades de la automatización de pruebas y las implementa

•Experiencia como tester•Conocimiento técnico de diseño y automatización de pruebas•Conocimiento de programación•Conocimiento de uso de herramientas

Administrador del sistema de pruebas •Responsable de cumplir los requisitos del sistema de pruebas

•Administración de sistemas•Conocimiento de herramientas de desarrollo y pruebas•Sistema de bases de datos•Redes•Instalación y operación de SW del sistema

Probador Software •Ejecuta las pruebas de acuerdo a los casos de prueba

•Conocimiento básico del SW•Conocimiento básico de pruebas•Operación y uso de herramientas de pruebas•Conocimiento respecto de los objetos de prueba

Experto técnico •Asiste al equipo de pruebas •Administración o diseño de bases de datos•Experto en interfaces de usuario•Experto en redes*** En algunas ocasiones son necesarias competencias especiales no relacionadas a las pruebas ***

Organización de equipos de pruebas

Dirección de equipos de pruebas

Jefe de pruebas

QuéQuién

Actividades de infraestructura de pruebas

Equipo de pruebas

Diseño de casos de prueba

Equipo de pruebas funcionales

Ejecución de pruebas

Equipo de pruebas

Evaluación de pruebas

Equipo de pruebas funcionales

Planificación Especificación de casos de prueba Ejecución Evaluación y control

Lider de pruebas Probador

•Organización del equipo de pruebas•Planificación de pruebas (plan de calidad corporativo)•Planificación de los ciclos de prueba•Estrategia de pruebas, decisión de automatización•Medición y control de pruebas•Introducción de un sistema de gestión de incidencias•Introducción de un sistema de gestión de configuración•Generación de informes de resultado y progreso para dirección de la configuración•Redacción del plan de pruebas (métodos, recursos y plazos)

•Asiste en la implementación y planificación de las actividades de pruebas•Desarrolla los diseños de casos de prueba y ejecución de pruebas•Revisa los casos de prueba diseñados por otros probadores•Asiste en la generación de informes de pruebas•Asiste en la implementación de la automatización de pruebas

Actividades de planificación de pruebas

•Tareas planeadas con antelación•Asignación de recursos•Hacer un plan de prueba maestro•Definir nivel de calidad•Controlar constantemente•La información de las actividades ayuda a afrontar riesgos en los cambios

Plan de aseguramiento de calidad (IEEE730)

•Organización del proyecto•Documentos que cubren el ciclo de vida de desarrollo •Estándares, métodos y convenciones•Revisiones y auditorías durante el ciclo de vida del desarrollo•Proceso de pruebas•Documentación de errores, acciones correctivas

Plan de pruebas maestro

•Cubre todas las fases del proceso de pruebas•Las reglas se fijan de acuerdo a objetivos de las pruebas•Se realiza con el objeto de cubrir los resultados a partir de la fase de planificación•Cuenta con una extensión dinámica•El estándar IEEE 829 aporta una estructura de pruebas maestro

Plan de pruebas de acuerdo al estándar IEEE 829

1. Introducción2. Suposiciones3. Elementos de pruebas4. Características / presentaciones sujetas a pruebas5. Características / presentaciones no sujetas a pruebas6. Enfoque7. Criterios de paso / fallo8. Criterios de suspensión /reanudación

9. Entregables de pruebas10. Tareas de pruebas11. Necesidades relativas al entorno12. Responsabilidades13. Dotación del personal y formación 14. Calendario15. Riesgos y contingencias16. Aprobación

Actividades a realizar

•Estrategia de pruebas: Describe los niveles de prueba y la intensidad de las pruebas Establece criterios de entrada y salida incluyendo métricas No es viable probar el sistema completo ayuda a centrar la atención en actividades que presentan un riesgo de fallo más alto

•Planificación de recursos Estimar el esfuerzo de los miembros del equipo Cuenta con un calendario detallado para gestionar todas las actividades

•Planificación de pruebas Gestionar el tiempo Priorizar pruebas Selección de herramientas Documentar

•Criterios de entrada Define cuándo comenzar a probar•Criterios de salida Cobertura de código

Cobertura de riesgo Aborto de pruebas debido a razones de tiempo, costos o calidad Tasa de detección de errores Economía del proceso de pruebas

Enfoques de prueba Preventivo Reactivo Analístico heurísticos

Factores de estimación de pruebas

•Experta Ventajas: Vinculadas a la planificación del proyecto / da origen a la información detallada / tareas asignadas a grupos

Desventajas: Extensivo y caro / omisión de tareas / errores heredados•Basado en analogías Ventajas: Simple y efectivo / logra valores precisos

Desventajas: requiere personal con experiencia / no cubre todos los aspectos de un proyecto / conduce a debates por la validez de la estimación

•Basada en porcentajes Ventajas: Muy simple y potenteDesventajas: no muy precisa / es necesaria mucha experiencia / conduce a debates difíciles / tiene en cuenta pruebas del desarrollador

Seguimiento y control de pruebas

•Planificación de pruebas: Deben ser iniciadas•Seguimiento de pruebas: Control de las actividades de pruebas con el objeto de detectar desviaciones•Control de pruebas: corrección del rumbo de las actividades de pruebas cuando sea necesario

Control de pruebas

•Es una tarea de gestión•Medidas correctivas como respuesta•Evaluación del cierre de pruebas•Medidas Previsión de recursos adicionales

Reducción del esfuerzo aplicado Documentos para informar respecto a cambios

Gestión de la configuración

•Objetivo generar datos•Participantes con diferentes roles•Tiene un rol de apoyo durante el proyecto•Se debe desarrollar un plan de gestión de la configuración•El IEEE 828 aporta un estándar•Es necesaria durante todas las fases del proyecto•Se requiere de una herramienta para proyectos grandes•Tipos de la configuración GC

del cambio de entregas de versiones

•Problemas abordados ¿Cuál es la versión actual? ¿Qué ha sido modificado, cuándo y quién lo modificó? ¿Qué versión del fichero ha sido probada? ¿Qué artefactos se corresponden?

Riesgo y proceso de prueba

•Riesgos asociados a la organización•Riesgos tecnológicos•Riesgos ambientales•Riesgos de producto relacionados con el producto suministrado•Gestión de riesgos Identificar, analizar y priorizar

Influencia del riesgo (métodos de prueba, alcance de las pruebas, orden de ejecución)Lista de evaluación de riesgo

Beneficios:• Método de prueba seleccionado para mitigar riesgos• Se usa el alcance de las pruebas y se tiene en cuenta para su reducción

Gestión de incidencias

Detección de errores

•Ejecutar casos de prueba•Analizar desviaciones•Seguimiento ( con un sistema de gestión de incidencias

Estructura de un informe de incidencias

Detalles que puede incluir un informe de incidencias Elementos que puede incluir un informe de incidencias

Datos de la incidencia Clasificación de errores Descripción Registro histórico

•Número único del defecto•Objeto de prueba, paso de prueba•Entorno de pruebas•Nombre del autor del informe de incidencias•Fecha de la primera ocurrencia

•Clasificación de defecto•Estado del defecto•Prioridad

•Caso de prueba•Resultado del defecto / modo de fallo•Descripción de la desviación para facilitar su resolución•Referencias cruzadas a informes relacionados•Comentarios•Acciones correctivas tomadas

•Hora usuario que ha realizado cambios•Muchos sistemas hacen un seguimiento automático de cambios en el ciclo de vida del incidente/error

Clase y prioridad del defecto

Clases: Defecto críticoDefecto mayorDefecto medioDefecto menor

Prioridad: Impacto sobre la funcionalidad del programaImpacto sobre el proyecto, sobre el clientePosibilidad de aportar una solución (corrección)

inmediata al problema o en la siguiente entrega

El criterio es la influencia en la usabilidad del producto

La prioridad rige la urgencia de la corrección

Estados de un defecto

NuevoAbierto

RechazadoInspección

En observación

Trabajo en progresiónRepetición de pruebas

FinalizadoNo resuelto

Nuevo

Trabajo en progresión

Inspección

Abierto

Rechazado

En observación

No resuelto FinalizadoRepetición de prueba

Las herramientas de gestión de incidencias ofrecen una amplia variedad de informes de estadísticas de defectos.

herramientas de soporte para pruebas

• Mejorar la eficiencia de las actividades de prueba a través de la automatización de tareas repetitivas •Automatizar actividades que requieren recursos significativos cuando son ejecutados de forma manual•Mejorar la fiabilidad de pruebas

Clasificación • Herramientas unitarias: dan soporte a una tarea o actividad específica•Paquetes de herramientas; cubren varias tareas e integran varias herramientas unitarias•Herramientas intrusivas: pueden interferir en la ejecución del objeto de prueba y pueden provocar que difiera respecto del objeto en el entorno real

De gestión de pruebas (gestión, recopilación, clasificación y administración de casos de prueba)

De gestión de requisitos (acopio, asignación de prioridades, establecer la referencia entre requisitos y casos de prueba, identificar requisitos faltantes)

De gestión de gestión de incidencias (registro y seguimiento de incidencias, almacenamiento de solicitudes de cambio, asignación de prioridades, evaluaciones y progreso de las pruebas, flujo de trabajo)

De gestión de gestión de la configuración (seguimiento de las versiones de los componentes, gestión de versiones de herramientas, administración del código fuente y código objeto, referencias a la gestión de pruebas)

Herramientas de soporte para pruebas estáticas

Forma más rentable de prevenir y detectar defectos en el proceso de desarrollo

Herramientas para revisiones: apoyo al proceso de revisión, documentación de los resultados, evaluación, listas de comprobación, revisiones de líneas, trazabilidad entre documentos y código fuenteHerramientas de análisis estático: Cumplimento de estilos de codificación y código seguro, análisis de la estructura del código

Herramientas de modelado: Análisis de modelos de datos, de documentos de especificación, modelos de diseño de objetos, diagramas de estados, comprobación de consistencia

Herramientas de soporte para pruebas estáticas

Herramientas de diseño de pruebas: Utilizadas para generar entradas de prueba o pruebas ejecutables, interfaces gráficas de usuario, diseño de modelos o código

Herramientas de preparación de datos de prueba: Manipulan bases de datos, ficheros y se clasifican dependiendo de la fuente de datos

Generadores de datos de prueba asociados a bases de datos. Obtienen datos a partir del reconocimiento de estructuras y contenidos.

Generadores de datos de prueba Basados en el código fuente. Sólo pueden generar datos de prueba en base al código aportado, no identifican funcionalidad ausente/faltanteGeneradores de datos de prueba asociados a la interfaz. Obtienen clases de equivalencia y valores límite

Generadores de datos de prueba basados en la especificación. Requieren uso de una estricta notación formal; si se ayuda de una herramienta CASE pueden aportar una buena base para la herramienta

Herramientas de soporte para la ejecución y registro de pruebas

Robots de pruebas: el avance de la prueba es automático, comparan resultados reales con los esperados, permite repetición automática, apropiados para pruebas de regresión

Incluyen: entrega de datos, recepción de datos o escritura en el registro del comportamiento de la salida, documentación de la ejecución de pruebas

Depurador: detecta errores en el código, comprueba sentencias unitarias y condiciones, las variables pueden ser definidas de forma individual y referenciadasComparadores de prueba: compara resultados esperados y obtenidos, usan funcionalidades de filtro, pueden ser una herramienta independienteArnés de prueba: Pruebas de componente, simulación del entorno que debe ser tan próximo como sea posible.Controladores de prueba: Permite acceder al objeto de prueba cuando aun no ha sido implementada la interfaz, regula la entrada de datos y la salida, registra resultados realesStubs: Simulan la funcionalidad del componente Herramientas de simulación de cobertura: Pueden ser o no intrusivas, miden el % de un tipo de estructura de código, cuentan sentencias, ramas o decisiones, módulos o llamadas a funciones.Herramientas de pruebas de seguridad: evalúa características de seguridad, capacidad del software de proteger la confidencialidad, integridad, autenticación, autorización, disponibilidad y no repudio de datos, utilizadas por expertos

Herramientas de soporte para la ejecución y registro de pruebas

Herramienta de análisis dinámico: Detectan defectos que sólo son evidentes cuando el software se encuentra en ejecución, con la asignación de punteros o su aritmética, importante para multisistemas.Herramientas de prueba de rendimiento / pruebas de carga / pruebas de estrés: Monitorización, medición e información respecto del comportamiento de un sistema, creación de usuarios virtuales, generan carga sintéticaHerramientas de monitorización: analiza de forma continua, verifica e informa respecto de los recursos de un sistema específico.

Evaluación de la calidad de los datos

•Los datos son el centro de algunos proyectos como los de migración o data warehouse•Puede variar en términos de criticidad y volumen•Son necesarias herramientas para verificar la conversión de datos•Dimensiones de la calidad de los datos•Libertad de errores representa la corrección de los datos

Beneficios y riesgos del soporte de herramientas para pruebas

El uso de herramientas de pruebas causan costes y

esfuerzos

Las ventajas del uso de la herramienta deben superar los

costes

Beneficios Los riesgos que incluye el uso de la herramienta

Despliegue erróneo de la herramienta

•Aportando la herramienta adecuada•Desarrollando pericia en la herramienta•Adaptando la herramienta•Que los esfuerzos de la administración queden asegurados•Tiempo y esfuerzo en la operación de la herramienta

•Un análisis coste beneficio debe ser realizado por anticipado•El beneficio total solo será manifestado con el uso de la herramienta en más de un proyecto

•Reducción del trabajo repetitivo•Iteración de actividades•Mayor consistencia y repetitividad•Evaluación objetiva•Facilidad de acceso•Gestión de datos con herramientas de prueba que permite diversidad de evaluaciones•Aporta información para mejor toma de decisiones

•La funcionalidad de la herramienta no cumple con las expectativas•La usabilidad de la herramienta no cumple con las expectativas•Se ha infravalorado el tiempo y esfuerzo necesarios para lograr los beneficios•No todos los requisitos de calidad se han alcanzado•Se han sobreestimado los beneficios•Los costes se han subestimado al igual que los esfuerzos por mantener activa la herramienta•Excesiva dependencia a la herramienta

•Descuido de las relaciones e interoperabilidad de entre herramientas críticas•Riesgo de que el fabricante de una herramienta suspenda sus actividades comerciales •Respuesta pobre del vendedor para el soporte, actualización y corrección de los defectos•Riesgo de suspensión de proyecto de herramienta de código abierto•Expectativa de que la herramienta resolverá todos los problemas de las pruebas•La herramienta no compensa ni sustituye procedimientos •Incapacidad de soportar una nueva plataforma

Pasos hacia la introducción de una herramienta

•Evaluación•Definición de requisitos•Evaluar criterios de calidad adicionales•Prueba de concepto (si la herramienta va a aportar los efectos esperados)•Evaluación del fabricante•Uso de la herramienta•Evaluación de la formación (conocimientos / capacidades del equipo actual)•Relación coste-beneficio

Ventajas de un proyecto piloto:•Llegar a conocer a detalle la

herramienta (puntos fuertes y débiles)

•Establecimiento de interfaces con otras herramientas

•Definir informes de acuerdo con los estándares de la organización

•Evaluar si la herramienta cumple con los beneficios esperados

•Estimar si el coste de despliegue se encuentra dentro del alcance

Factores de éxito en el despliegue de SW:

•Introducción y lanzamiento en la totalidad de la organización

•Hacer obligatorio el uso de la herramienta para los flujos de trabajo

y procesos respectivos•Guías de usuario para el despliegue

de la herramienta•Los usuarios deben tener acceso a la

formación adecuada•La experiencia adquirida debe estar

disponible para todos•El uso en curso de la herramienta

debe ser objeto de seguimiento para mejorar la aceptación