Presentación de Alejandro Magdits, Socio de Consultoría de EY Perú (Ernst & Young).

1. 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

2. Página 2
Pruebas

3. 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

4. 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

5. Página 5
Costo de corregir defectos

6. Página 6
Costo de corregir defectos
Presentation title
100%

7. 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

8. 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.

9. 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

10. 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.

11. Página 11
Tipos de pruebas

12. 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

13. 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

14. Página 14
Estándar ISO / IEC 29119

15. 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

16. Página 16
Estándar ISO / IEC 29119
Proceso 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

17. 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 29119
Procesos de gestión de las pruebas
Control y
seguimiento
Planificació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

18. Página 18
Diseño e
implementación
de pruebas
Estándar ISO / IEC 29119
Procesos 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

19. 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

20. Página 20
Conclusión

21. 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

22. 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