Control de Calidad en el Desarrollo de Aplicaciones
Modelo Operacional de Pruebas y Certificación
●● Modelo Operacional de Pruebas y CertificaciónModelo Operacional de Pruebas y Certificación
•• MetodologíaMetodología
Agenda
•• IntroducciónIntroducción
•• MetodologíaMetodología •• EntregablesEntregables
•• TiposTipos
•• AmbientesAmbientes
El Modelo en V proporciona un marco de desarrollo estructurado, enfatizando la calidad de la construcción desde la fase de requerimientos iniciales hasta la fase de pruebas. El Modelo en V exige que los productos principales del proyecto sean verificados,validados , y probados . El proceso de verificación y validación es un intento de identificar problemas en las fases más tempranas del ciclo de vida del proyecto y asegurar que las especificaciones son completas, correctas y cumpliendo estándares. La prueba asegura
MetodologíaIntroducción
especificaciones son completas, correctas y cumpliendo estándares. La prueba asegura que las especificaciones han sido correctamente desarrolladas y que la solución responde a los requerimientos de negocio y rendimiento del proyecto.
El esfuerzo de un desarrollo comienza en el lado izquierdo del Modelo en V, con las actividades de análisis y diseño. El proyecto se detalla de arriba abajo, tomando decisiones y añadiendo más especificaciones en cada fase. Cuando termina el diseño, comienza la construcción. Una vez que ésta se completa, el producto pasa, a través de las actividades de pruebas, a la zona derecha del Modelo en V. Durante las primeras fases de prueba, el foco se centra en los componentes individuales. Según se progresa en esta fase, el foco pasa a la funcionalidad y al logro de los requerimientos establecidos. Mientras tanto, las acciones de verificación y validación se van ejecutando a lo largo de todo el ciclo de vida del proyecto que sigue el Modelo en V.
MetodologíaIntroducción
Especificaciones de Requerimientos
Obtener los requerimientos de
Usuario
Analizar los requerimientos del
Preparar y Ejecutar Pruebas de Aceptación de Usuario
Preparar y Ejecutar Pilotos y Simulaciones
Salida a ProducciónMetodología de Prueba – Modelo V
Preparar y Ejecutar
Flujo de Trabajo Verificación ValidaciónPruebas: Probar que los desarrollos cumplen las especificaciones iniciales
Diseño Conceptual de Aplicación
Arquitectura de Aplicación
Especificaciones de Programación
requerimientos del sistema
Diseñar Aplicación
Diseñar Procesos Automatizados
Generar y Codificar Unidades de Programación
Preparar y Ejecutar Prueba Unitaria
Preparar y Ejecutar Prueba de Integración
Preparar y Ejecutar Prueba de Desempeño
Preparar y Ejecutar Prueba de Producto
MetodologíaIntroducción
Verificación
• La Verificación es un control que asegura que todos los componentes se han construido correctamente a partir de los datos de entrada y los estándares establecidos.
. Fase Tipo Documentación requerida
Diseño Técnico Peer Review (Revisiones entre Iguales)
Diseño Tecnico DetalladoMatriz de Casos de Pruebas UnitariasCuestionario de Revisiones Peer Formulario de Resultados de Revisión Peer.Guías de diseño vigentes en Telefónica Movistar
Construcción y Prueba Unitaria
Peer Review (Revisiones entre Iguales)
Código FuenteMatriz de Casos de Pruebas UnitariasResultados de prueba Unitaria/SistemaCuestionario de Revisión PeerFormulario de Resultados de Revisión PeerGuías de Codificación vigentes en Telefónica Movistar
MetodologíaIntroducción
Validación
• La validación es efectuada para asegurar que los sistemas/productos que están siendo desarrollados pueden ser usados como fue previsto. En otras palabras, la validación puede asegurar que las cosas están hechas de forma correcta.
• La validación se articulará en base a los puntos de transición, definidos como puntos en el ciclo de vida de la aplicación que hay un movimiento de los entregables, debido a la ciclo de vida de la aplicación que hay un movimiento de los entregables, debido a la finalización de una fase del ciclo de vida y que implica el movimiento del entregable entre equipos y/o responsables.
.
Fase Técnica de validación
Realizado por Criterio de Aceptación
Construcción y Prueba Unitaria
Prueba Analista Programador
No deberán quedar Informes de Errores de SW que no sean de tipo distinto a mejora.
MetodologíaIntroducción
� El Modelo V engloba toda la metodología y enfoque de pruebas de Accenture, siendoeste un modelo de pruebas validado y actualizado constantemente.
� El Modelo V provee un marco estructurado de pruebas a lo largo de todo el procesode desarrollo, enfatizando en la calidad de la fases iniciales del requerimiento hasta lafase final de pruebas.
� En el Modelo V cada etapa sucesiva de pruebas garantiza que el entregable de cada faseimplemente las especificaciones para esa etapa, proporcionando una continua verificacióny validación a lo largo de todo el desarrollo.
� La utilización de este modelo de pruebas conlleva a una disminución significativa delnúmero de errores que se pueden encontrar en Producción después de cadaimplementación.
� La continúa verificación y validación a lo largo de todo el proceso de desarrollo permiteuna detección temprana y rápida de los defectos.
●● Modelo Operacional de Pruebas y CertificaciónModelo Operacional de Pruebas y Certificación
Agenda
•• IntroducciónIntroducción
•• MetodologíaMetodología •• EntregablesEntregables
•• TiposTipos
•• AmbientesAmbientes
Metodología Tipos
A continuación se muestra una tabla con los distintos tipos de prueba que deben ser
planificadas y ejecutadas para verificar cada aplicación, al igual que el responsable de la
ejecución y el ambiente en el cual debe ejecutarse cada prueba:
Tipo de Prueba Responsable
PRUEBAS UNITARIAS
PRUEBAS FUNCIONALES Y DE INTEGRACIÓN
PRUEBAS DE ACEPTACIÓN DE USUARIO
Equipo de Desarrollo
Pruebas clientes
PRUEBAS DE DESEMPEÑO
Por definir
Por Definir
Debe existir una separación física y funcional entre las tareas de desarrollo y pruebas. Este
enfoque mejora el desempeño de los equipos responsables de estas actividades
Metodología Tipos
Equipo de Pruebas únicoPruebas Unitarias
Programación
Múltiples Equipos de Desarrollo
Pru
ebas
F
unci
onal
es y
de
Inte
grac
ión
Pru
ebas
de
Ace
ptac
ión
de U
suar
io
Pru
ebas
de
Des
empe
ño
Unitarias
Pruebas Unitarias
Pruebas Unitarias
Pruebas Unitarias
Programación
Programación
Programación
PRUEBAS UNITARIAS
Objetivo:
El objetivo de las Pruebas Unitarias es probar los elementos más
pequeños de la aplicación verificando que los flujos de control y
de datos han sido cubiertos y funcionan según lo esperado
Alcance:Roles:
Metodología Tipos
Alcance:
• Este nivel de prueba incluye una revisión del código fuente y
una prueba completa de la lógica del programa
• Todas las líneas de código deben ejecutarse al menos una vez
para garantizar que cumplen con las especificaciones del
diseño técnico
• Luego de la revisión del código, se prueba ejecutando el
programa para validar contra las especificaciones técnicas
establecidas
• La meta de la prueba es probar tantas líneas de código
involucradas como sea posible
Roles:
El rol responsable de la planificación
y ejecución de las Pruebas Unitarias
es el Analista Programador
Entregables:Los entregables relacionados con las
Pruebas Unitarias son:• Resultados de Prueba
Metodología Tipos
Datos de Prueba
Las Pruebas Unitarias pueden realizarse con datos limitados de
prueba.
Cómo obtener datos para las Pruebas Unitarias:
• Cargar archivos de texto desde la base de datos de
PRUEBAS UNITARIAS
• Cargar archivos de texto desde la base de datos de
producción y convertir la data utilizando herramientas de
conversión de datos
• Crear nuevos datos . Esto puede realizarse utilizando
herramientas de Generación de Datos o ingresando los
datos directamente en la Base de Datos.
Los datos para las Pruebas Unitarias deben ingresarse en el
ambiente de desarrollo.
Metodología Tipos
Criterios de Entrada
• ¿Se ha aprobado el diseño técnico?
• ¿Se han identificado los casos de prueba y los resultados
esperados?
Criterios de Salida
PRUEBAS UNITARIAS
Criterios de Salida
• ¿Se han probado todos los casos?
• ¿Se documentaron todos los resultados obtenidos?
• ¿Se documentaron todos los errores identificados?
• ¿Los errores identificados han sido corregidos o planificada su
corrección?
• ¿El módulo ha sido revisado por el líder del equipo?
Aspectos a considerar durante la ejecución de las P ruebas Unitarias:
•Se prueban todos los casos de lógica funcional
•Todas las variables se inicializan correctamente
•Todos los ciclos se completan exitosamente
•La codificación cumple con los estándares establecidos por
Metodología Tipos
PRUEBAS UNITARIAS
•La codificación cumple con los estándares establecidos por Banco
•Se prueba la validación de campos tanto para valores correctos e incorrectos
•Se prueban todos los manejadores de errores para los flujos del programa
•Los contadores son asignados adecuadamente
•Las nuevas estructuras de datos son compatibles con las ya existentes
•Las validaciones y el diseño de pantallas es consistente con los estándares de diseño del Banco
•Todos los cálculos generan resultados correctos
•Los cálculos sólo pueden realizarse con datos numéricos válidos. Las reglas de redondeo se aplican correctamente.
Aspectos a considerar durante la ejecución de las P ruebas Unitarias (continuación):
•Se manejan correctamente los números positivos y negativos
•Se prueban todos los valores de cada campo de mensaje
•Las entradas no son rechazadas en el procesamiento
•Todos los módulos hacen un manejo correcto las condiciones
PRUEBAS UNITARIAS
Metodología Tipos
•Todos los módulos hacen un manejo correcto las condiciones de error y proveen mensajes adecuados
•Se prueba cada condición de error
•Se han efectuado pruebas para valores no numéricos y campos en posiciones incorrectas.
•Todos los acumuladores son asignados a cero al comienzo de las ejecuciones y puntos de corte
•Las interacciones entre múltiples ventanas dentro de un mismo diálogo o la misma función de negocio se efectúan según lo diseñado.
•Todos los errores identificados han sido corregidos o planificada su corrección
•Se realizarán Pruebas de Regresión para verificar que las correcciones efectuadas no afectan negativamente casos ya probados
PRUEBAS FUNCIONALES/INTEGRACIÓN
Objetivo:El objetivo de las Pruebas Funcionales / Integración es validar que la aplicación en su totalidad cumple con los requerimientos funcionales y de negocio para asegurar que los componentes del sistema operan adecuadamente al ser combinados
Roles: Alcance Funcional de las Pruebas Funcionales / Int egración
Metodología Tipos
Roles:
Entregables:
• Plan
• Casos
• Rutas
• Log
• Resultados
• Configuración del
Ambiente
El rol involucrado en las Pruebas Funcionales / Integración es Testing Movistar
• Se realiza cuando la aplicación esta funcionando como un todo. El objetivo es probar la funcionalidad completa del sistema así como también las interfaces existentes
• Valida que la aplicación cumple con los requerimientos funcionales
• Valida que las interfaces funcionan correctamente y que las funciones de negocio son soportadas entre los múltiples sistemas
Alcance Técnico de las Pruebas Funcionales / Integr ación• Valida que todas las aplicaciones han sido cargadas y
configuradas adecuadamente• Valida que la infraestructura técnica del banco soporta los
cambios de las aplicaciones, y que los cambios en la plataforma no impactan en el desempeño de las aplicaciones existentes
Metodología Tipos
Datos de Prueba
Las Pruebas Funcionales y de Integración deben realizarse con
datos limitados pero realistas, es decir, no se requiere utilizar los
datos completos de la Base de Datos de Producción.
Como obtener datos para las Pruebas de Integración:
PRUEBAS FUNCIONALES/INTEGRACIÓN
Como obtener datos para las Pruebas de Integración:
• Cargar archivos de texto desde la base de datos de
Producción y convertir la data utilizando herramientas de
conversión de datos
• Crear nuevos datos . Esto puede realizarse utilizando
Herramientas de Generación de Datos o ingresando los
datos directamente en la Base de Datos.
Los datos para las Pruebas de Integración deben ingresarse en
el ambiente de Pruebas antes del comenzar la ejecución
Criterios de Entrada
• ¿La fase de Pruebas Unitarias ha sido aprobada?
• ¿Los Planes de Prueba han sido revisados y aprobados?
• ¿Se han identificado y documentado los casos, rutas de prueba y resultados esperados?
PRUEBAS FUNCIONALES/INTEGRACIÓN
Metodología Tipos
• ¿Está listo el ambiente de Pruebas?
• ¿Se han preparado los datos para la Prueba Funcional y de Integración?
Criterios de Salida
• ¿Se han probado todas las rutas de prueba?
• ¿Los resultados obtenidos han sido documentados?
• ¿Se documentaron todos los errores identificados?
• ¿Los errores identificados han sido corregidos o planificada su
corrección?
• ¿Se han efectuado las revisiones y aprobaciones necesarias?
Metodología Tipos
Aspectos a considerar durante la ejecución de las P ruebas Funcionales y de Integración:
Funcional
•Las interacciones entre las múltiples aplicaciones funcionan según lo diseñado
•La aplicación soporta los procesos de negocio
PRUEBAS FUNCIONALES/INTEGRACIÓN
•La aplicación soporta los procesos de negocio
•Todas las funciones se efectúan según lo requerido con entradas esperadas e inesperadas
•Todas las excepciones son manejadas adecuadamente o no interfieren con los procesos existentes
•Todos los errores han sido solventados o planificada su corrección
Técnico
•La plataforma técnica existente soporta los nuevos cambios
•El desempeño de las aplicaciones existentes no se ve afectado por los cambios en la infraestructura técnica
•Aspectos de prueba que pueden o no ser obvios para el usuario, como por ejemplo: recuperación y arranque
Metodología Tipos
PRUEBAS DE ACEPTACIÓN DE USUARIO
Objetivo:El objetivo de las Pruebas de Aceptación de Usuario es verificar que la aplicación está lista y puede ser utilizada por el usuario final para desempeñar las funciones del negocio
Alcance:Roles: Alcance:
• Se enfoca en validar que los requerimientos del usuario /
negocio han sido implementados adecuadamente y soportan las
necesidades y los procesos de negocio realizados por los
usuarios
• Los usuarios validan que otros requerimientos de calidad sean
cumplidos (facilidad de uso del sistema, datos de referencia,
integridad de reportes y desempeño del sistema)
• Se prueba que la misma función de negocio trabaja
adecuadamente en escenarios distintos.
• Se verifican los valores de cada campo de mensaje
• Se prueba que resultados y totales son generados correctamente
por cada función de negocio
Roles:
Entregables:
• Plan
• Casos
• Rutas
• Log
• Resultados
• Configuración del
ambiente
• Testing Movistar
Los roles involucrados en las Pruebas de Aceptación de Usuario son:
Metodología Tipos
Datos de Prueba
Al igual que en las Pruebas Funcionales y de Integración, las
Pruebas de Aceptación de Usuario deben realizarse con data
limitada pero realista, eso significa que no es necesario utilizar la
Base de Datos de Producción completa
PRUEBAS DE ACEPTACIÓN DE USUARIO
Los datos ingresados en el ambiente de pruebas deben
refrescarse antes de la ejecución de estas pruebas
Creación y modificación de Datos de Prueba
Refrescamiento Datos de Prueba
Pruebas Unitarias
Programación
PRUEBAS DE ACEPTACIÓN DE USUARIO
Metodología Tipos
Criterios de Entrada
• ¿Se aprobaron las Pruebas Funcionales y de Integración?
• ¿Se identificaron y documentaron los casos, rutas de pruebas y resultados esperados para estas pruebas?
• ¿Se ha acordado y aprobado la participación y disponibilidad de los usuarios?
• ¿Esta listo el ambiente de pruebas?
• ¿Se han preparado los datos de prueba?
Criterios de Salida
• ¿Se han probado todas las rutas definidas para estas pruebas?
• ¿Se han documentado los resultados obtenidos?
• ¿Se documentaron todos los errores identificados?
• ¿Los errores identificados han sido corregidos o planificada su
corrección?
• ¿Se han efectuado las revisiones y aprobaciones necesarias?
Metodología Tipos
Aspectos a considerar durante la ejecución de las p ruebas:
• La aplicación soporta los procedimientos y la operativa de los
usuarios
• La aplicación soporta los procesos para todos los perfiles (tipos)
de usuario
PRUEBAS DE ACEPTACIÓN DE USUARIO
• La misma función de negocio trabaja adecuadamente bajo
distintos escenarios.
• Cada proceso afecta solamente a la data esperada sin
inclusiones o exclusiones no previstas
Metodología Tipos
PRUEBAS DE DESEMPEÑO
Objetivo:El objetivo de las Pruebas de Desempeño es identificar y corregir problemas de rendimiento de las aplicaciones antes de su pase a producción
Alcance:Roles: Alcance:
• Prueba que los procesos de negocio pueden ejecutarse con los
niveles de servicio requeridos, mientras trabaja con picos reales
de carga de trabajo, en un ambiente completamente integrado
• El desempeño del sistema deberá ser monitoreado en todas las
áreas de la funcionalidad de la aplicación (por ejemplo: tiempos
de respuesta en el front end, planificación de tareas batch,
servidores, bases de datos, redes, etc.)
• Las Pruebas de Desempeño deben probar específicamente, el
comportamiento del sistema bajo volúmenes normales,
volúmenes máximos y en el nivel en el cual comienza a decaer
el desempeño de la aplicación
Roles:
Entregables:
• Plan
• Casos
• Log
• Resultados
• Configuraciones
del ambiente
• Analista de Homologación
• Arquitectos
• Infraestructura
Los roles involucrados en las Pruebas de Desempeño son:
PRUEBAS DE DESEMPEÑO
Metodología Tipos
Con el fin de identificar problemas de desempeño antes de realizar el pase a Producción, el Banco debe ejecutar los siguientes niveles de prueba:
CAPACIDAD Y DISPONIBILIDAD
• Prueba de Carga: Somete al servidor a condiciones de carga análogas a las del ambiente de Producción.análogas a las del ambiente de Producción.
• Pruebas de Estrés: Somete al servidor a aquellas condiciones de carga en las cuales el desempeño comienza a desmejorar.
CONTINGENCIA
• Pruebas del Ambiente Técnico: Garantiza que el hardware, la red y los componentes del Sistema Operativo se han instalado correctamente y se integran de forma adecuada.
• Pruebas de Recuperación Técnica: Confirma que los eventos técnicos que se producen durante una recuperación del desastre operan adecuadamente.
PRUEBAS DE DESEMPEÑO
Metodología Tipos
• Prueba de Aplicación: Garantiza que las aplicaciones del negocio están correctamente instaladas para probar la funcionalidad de recuperación
• Pruebas de Invocación: Garantiza que el proceso de recuperación y los procesos que facilitan los servicios de recuperación se ejecutan dentro del rango de tiempo definido y de manera apropiada.
PRUEBAS DE DESEMPEÑO
Metodología Tipos
Datos de Prueba
Pruebas de Desempeño BatchCon el fin de obtener resultados significativos, las Pruebas de Desempeño Batch deben ejecutarse con una base de datos completa de Clientes, Cuentas y Transacciones. La Base de Datos de Pruebas de Desempeño puede La Base de Datos de Pruebas de Desempeño puede prepararse mediante las siguientes opciones:
• Cargando archivos de texto desde la base de datos de Producción y adecuando la data utilizando herramientas de conversión de datos
• Creando nuevos datos . Esto puede realizarse utilizando Herramientas de Generación de Datos o ingresando los datos directamente en la Base de Datos.
PRUEBAS DE DESEMPEÑO
Metodología Tipos
Datos de Prueba
Pruebas de Desempeño OnlineExisten dos opciones para medir el desempeño para transacciones Online:
• Utilizando usuarios clave del negocio en transacciones • Utilizando usuarios clave del negocio en transacciones importantes y cronometrar el tiempo de respuesta.
• Utilizando una herramienta de pruebas que puede ser configurada para ejecutar scripts de prueba y capturar el desempeño
PRUEBAS DE DESEMPEÑO
Metodología Tipos
Cuando ejecutar Pruebas de Desempeño:
Pruebas Desempeño Batch
Deben utilizarse para probar: • Ejecuciones diarias de procesos Batch
• Ejecuciones de Batch en fin de día
• Ejecuciones de Batch en fin de mes• Ejecuciones de Batch en fin de mes
• Ejecuciones de Batch en fin de año
• Interfaces Batch prioritarias con otras plataformas y redes
externas
Pruebas Desempeño Online
Las Pruebas de Desempeño Online deben enfocarse en probar
canales e interfaces con un volumen alto de transacciones:
• Transacciones de Cajeros
• Transacciones de ATM
PRUEBAS DE DESEMPEÑO
Metodología Tipos
Cuando ejecutar Pruebas de Desempeño:
Pruebas Desempeño Online (continuación)
• Otros canales prioritarios (ejemplo: banca electrónica, banca
por teléfono, etc.) Banco debe asignar prioridades a las
Pruebas de Desempeño para cubrir solo los canales más
utilizados o aquellos que generan un volumen significativo
• Asignar prioridad a las interfaces online entre aplicaciones.
Banco debe priorizar las Pruebas de Desempeño sólo para
cubrir aquellas interfaces entre aplicaciones que son más
utilizadas o generan un volumen importante de transacciones.
PRUEBAS DE DESEMPEÑO
Metodología Tipos
Criterios de Entrada
• ¿Se aprobaron las Pruebas de Integración?
• ¿Se identificaron y documentaron los casos de prueba y resultados esperados para las Pruebas de Aceptación de Usuario?
• ¿Esta listo el ambiente de Pre-producción?• ¿Esta listo el ambiente de Pre-producción?
• ¿Los datos para las Pruebas de Desempeño han sido preparados?
Criterios de Salida
• ¿Se han probado todos los casos?
• ¿Se han documentado los resultados obtenidos?
• ¿Se documentaron todos los errores identificados?
• ¿Se han efectuado las revisiones y aprobaciones necesarias?
Metodología Tipos
PRUEBAS DE DESEMPEÑO
Aspectos a considerar durante la ejecución de las P ruebas de Desempeño:
Capacidad / Disponibilidad
•La aplicación soporta el acceso de múltiples usuarios al servidor
•La aplicación soporta comportamientos habituales de los usuarios
•La aplicación soporta volúmenes mayores a los esperados
Contingencia
•Los procesos y mecanismos técnicos para la recuperación del sistema operan adecuadamente
•La cantidad de transacciones perdidas en caso de desastre no supera la cantidad esperada
•Las configuraciones de equipos redes y aplicaciones están en la versión correcta
•Los procedimientos de identificación de desastre, escalación e invocación operan según lo planeado
●● Modelo Operacional de Pruebas y CertificaciónModelo Operacional de Pruebas y Certificación
Agenda
•• IntroducciónIntroducción
•• MetodologíaMetodología •• EntregablesEntregables
•• TiposTipos
•• AmbientesAmbientes
Metodología Ambientes
A continuación se muestra una tabla con los distintos ambientes que deben ser
establecidos para el proceso de pruebas y su descripción:
Desarrollo
Tipo de Ambiente Descripción
� Utilizado por el programador para validar el funcionamiento de su desarrollo (Pruebas Unitarias)� Ambiente de naturaleza inestable debido a
los múltiples desarrollos que se llevan a cabo Desarrollo
Pruebas
los múltiples desarrollos que se llevan a cabo sobre esta plataforma� Contiene un conjunto de datos limitado y
muy cambiante a causa de las pruebas que se ejecutan en paralelo� Adecuado para pruebas puntuales de
funcionalidad
� Utilizado para realizar pruebas funcionales de integración y certificación de usuario� Ambiente integrado más estable donde se
encuentran instalados las versiones más recientes de las aplicaciones y estructuras de datos� Contiene un subconjunto de datos
especialmente generados para las pruebas a realizar