Upload
damned4
View
634
Download
10
Embed Size (px)
Citation preview
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