el diablo está en los detalles: calidad a través de las pruebas funcionales y técnicas en...
TRANSCRIPT
El diablo está en los detalles:
Calidad a través de las pruebas funcionales y técnicas en sistemas de información
10 de setiembre de 2015
Página 2
Pruebas
Página 3
¿Qué pasa con las pruebas en el mundo?
63% de las empresas que hacen uso intensivo de sistemas de información en su negocio, tienen una gestión de pruebas razonable que propicia la mitigación de los riesgos de fallas funcionales o técnicas en los sistemas de información.
78% de las empresas con problemas con la calidad funcional o técnica de sus sistemas tiene limitaciones en la gestión de pruebas funcionales o técnicas en sus sistemas de información.
84% de los casos en los que los requerimientos funcionales no están bien definidos impactando la calidad de las pruebas funcionales o técnicas en el sistema de información.
47% de las empresas que realizan pruebas funcionales tienen dificultades con la calidad de la ejecución de las pruebas.
Presentation title
Página 4
¿Qué es un defecto?
Un defecto provoca que un programa no cumpla de manera completa y efectiva aquello para lo que fue creado.
Un defecto es algo concreto, se puede identificar, describir y contabilizar.
La corrección del defecto tiene costo y su corrección toma tiempo.
Entre los tipos de defectos están: Documentación, sintaxis, organización (gestión de cambio, librerías, control de
versiones), asignación (declaración, ámbitos, nombres duplicados), Interfaz (dentro del mismo sistema o con otros externos), chequeo (mensajes de error, trazas, validaciones), datos (estructura, contenido), función (errores lógicos, bucles, recursividad), sistema (configuración, instalación, explotación), entorno (diseño, compilación, pruebas).
Presentation title
Página 5
Costo de corregir defectos
Página 6
Costo de corregir defectos
Presentation title
100%
Página 7
Distribución típica del origen de los errores 56% Requerimientos 7% Código 27% Diseño 10% Otros
Distribución típica del esfuerzo para resolver errores si se origina en: 82% Requerimientos 1% Código 13% Diseño 4% Otros
Estadísticas generales
Presentation title
Página 8
Distribución típica del origen de los errores 56% Requerimientos 7% Código 27% Diseño 10% Otros
Distribución típica del esfuerzo para resolver errores si se origina en: 82% Requerimientos 1% Código 13% Diseño 4% Otros
Estadísticas generales
Presentation title
La ausencia de una adecuada gestión de requerimientos tiene impacto en la calidad de la gestión de las pruebas.
Sin requerimientos bien definidos es probable que se requieran cambios que encarecen el proyecto.
Página 9
Costo de resolver el defecto
Costo de prevenir el defecto
Costo por daños ocasionados por el defecto
Costo de oportunidad por el tiempo afectado por el defecto
Costo por el impacto en la imagen del sistema en la empresa
Costo por el impacto en la confianza interna y del cliente
Costo por el impacto en la productividad del personal por afectar la motivación
Impacto de los defectos
Presentation title
Página 10
Costo de resolver el defecto
Costo de prevenir el defecto
Costo por daños ocasionados por el defecto
Costo de oportunidad por el tiempo afectado por el defecto
Costo por el impacto en la imagen del sistema en la empresa
Costo por el impacto en la confianza interna y del cliente
Costo por el impacto en la productividad del personal por afectar la motivación
Impacto de los defectos
Presentation title
Los defectos en el sistema crean una imagen negativa que afecta la asimilación fluida del sistema en la empresa.
Página 11
Tipos de pruebas
Página 12
Tipos de pruebas
Pruebas unitarias Objetivo: comprobar que un módulo de código funciona correctamente
Pruebas funcionales Objetivo: comprobar que el software desarrollado realiza de manera
funcionalmente correcta aquello para lo que fue desarrollado
Pruebas integración Objetivo: comprobar que los módulos que componen el código
desarrollado funciona correctamente una vez que estos están integrados entre si
Pruebas de validación o aceptación Objetivo: comprobar que el software desarrollado cumple con las
expectativas del cliente, tanto desde el punto de vista de la funcionalidad como de la satisfacción del cliente
Presentation title
Página 13
Tipos de pruebas
Pruebas de caja blanca Objetivo: probar el funcionamiento de la estructura de control definida
en la lógica (o configuración) del programa. Se ejecutan por lo menos una vez todos los flujos del programa.
Pruebas de caja negra Objetivo: comprobar que la funcionalidad del programa o del sistema
está operativa. Permite identificar: Funciones incorrectas o ausentes Errores de interface Errores de estructura de datos o acceso a BD externas Errores de rendimiento Errores de inicialización o de terminación
Presentation title
Página 14
Estándar ISO / IEC 29119
Página 15
Estándar ISO / IEC 29119
Estándar de prueba aplicable a todo tipo de sistemas.
Unifica e integra los conocimientos de tres generadores de estándares: BSI, IEEE, ISO/IEC.
Consiste de cuatro secciones relacionadas: Conceptos Procesos Documentación Diseño de pruebas
Modelo de procesos de prueba Procesos de prueba de la organización Procesos de gestión de pruebas Proceso de pruebas dinámicas
Presentation title
Página 16
Estándar ISO / IEC 29119Proceso de prueba de la organización
Presentation title
Proceso de prueba de la organización
Política de pruebas Estrategia de pruebas
► Objetivo► Alcance► Organización► Principios de gobierno
► Procesos ► Responsables► Productos► Técnicas► Herramientas
Página 17 Presentation title
Procesos de gestión de las pruebas
► Entender el contexto► Organizar el plan de pruebas► Identificar y analizar riesgos► Identificar las mitigaciones de
riesgos► Diseñar la estrategia de pruebas► Determinar el personal y
calendario► Registrar el plan de pruebas► Consenso del plan de pruebas► Comunicar el plan de pruebas
Estándar ISO / IEC 29119Procesos de gestión de las pruebas
Control y seguimientoPlanificación Finalización
► Preparación► Métricas y monitoreo► Reporte de progreso► Control de estado de
incidentes y pruebas completadas
► Archivar documentos y papeles de trabajo
► Desmantelar entorno de pruebas
► Lecciones aprendidas► Informar finalización
Página 18
Diseño e implementación de pruebas
Estándar ISO / IEC 29119Procesos de pruebas dinámicas
Presentation title
Procesos de pruebas dinámicas
Gestión de entorno
Ejecución Reporte de incidencias
► Especificaciones de las pruebas► Base de pruebas
(Cobertura, casos y procedimientos) trazabilidad
► Requisitos del entorno de pruebas
► Preparación y mantenimiento del entorno de pruebas
► Resultados de las pruebas
► Incidencias, correcciones y reprueba
► Estadísticas de control
► Reporte de avance► Informe de
incidencias
Página 19
Reportes de control
Gestión de Incidentes # de defectos Tiempo de solución # reincidencia de defectos # defectos requerimiento # defectos programación # defectos ejecución
Cobertura Casos de prueba funcional Flujos e interfaces # de casos probados # de casos sin defecto
Presentation title
Página 20
Conclusión
Página 21
Conclusión
Las pruebas son una parte integral del desarrollo o implementación de sistemas:
Las pruebas se inician con los requerimientos, no la codificación o configuración
Las pruebas son una actividad dinámica Prevenir es mejor que curar. Mientras más temprano se encuentre el defecto, mas económica es su
corrección Adoptar un estándar para las pruebas y mantenerlo en el tiempo Primero los procesos luego las herramientas No todas las personas pueden ejecutar pruebas bien, utilice equipos con
las competencias adecuadas Ejecutar pruebas planificadas en un entorno controlado proporciona
métricas objetivas Para obtener un retorno sobre la inversión, es necesario invertir
Presentation title
El diablo está en los detalles:
Calidad a través de las pruebas funcionales y técnicas en sistemas de información
10 de setiembre de 2015