la calidad del software y los procesos de testing

La Calidad del Software y los Procesos de Testing

GFI Informática


Índice

Introducción. Visión general del proceso de pruebas.Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a OpenSource Factoría de pruebas


Índice

Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a OpenSource Factoría de pruebas


“La calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. (IEEE, Std. 610-1990).

“Concordancia del software producido con los requerimientos explícitamente establecidos, con los estándares de desarrollo prefijados y con los requerimientos implícitos no establecidos formalmente, que desea el usuario” (Pressman, 1998)

Introducción. Definición de calidad software


Introducción Visión General del Proceso de Pruebas

El software lo desarrollan las personas, y éstas comenten errores; no se puede prevenir completamente la introducción de éstos defectos, pero si se puede trabajar para localizarlos especialmente los mas críticos.Decisiones de pruebas deberían basarse en satisfacción del cliente. Este es el objetivo último.Mayor parte de los defectos se concentran en las etapas tempranas del proceso de desarrollo y el costo de corrección aumenta a medida que permanece no detectado.De perogrullo: los defectos mas costosos son aquellos que no se detectan.


Planificación Estandar Evolución Real Ideal Pruebas

El proceso de Pruebas es una parte del ciclo de vida del Software.Interviniendo desde la concepción detallada de la aplicación y colaborando hasta su puesta final en producción, dando así en su conjunto un alto nivel de calidad.

RE

QU

ISIT

OS

DIS

EÑ

O A

LTO

NIV

EL

DIS

EÑ

O D

ETAL

LAD

O

INTE

GR

AC

IÓN

PRU

EBA

S

CO

DIF

ICAC

IÓN

INTE

GR

AC

IÓN

PR

UE

BAS

REQ

UIS

ITO

S

DIS

EÑ

O A

LTO

NIV

EL

DIS

EÑO

DE

TALL

AD

O INTE

GR

AC

IÓN

PR

UE

BA

S

CO

DIF

ICAC

IÓN

INTE

GR

AC

IÓN

PR

UE

BAS

RE

QU

ISIT

OS

DIS

EÑ

O A

LTO

NIV

EL

DIS

EÑO

DET

ALL

AD

O INTE

GR

AC

IÓN

PR

UE

BAS

CO

DIF

ICAC

IÓN


INTE

GR

AC

IÓN

PR

UEB

AS

CO

DIF

ICA

CIÓ

N


Introducción Visión General del Proceso de Pruebas


Introducción – Algo mas que pruebas Software

Pruebas Software

Gestión del Ciclo de

Vida de la Calidad

Software


Proceso caótico y no repetible

Metodología

Falta de Productividad

HerramientasProblemaCarencia

Recursos

Metodología

Herramientas

Introducción

La falta de cualquiera de estos vertices implica problemas evidentes:


Índice

Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrollo Uso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a open-sourceFactoría de pruebas


La evolución de los modelos específicos de test aumenta satisfactoriamente la calidad de dichos procesos y consecuentemente, los coloca en una posición relevante dentro de la ingeniería del software.Los modelos y estándares de evaluación de procesos de software ofrecen herramientas para establecer niveles de madurez de desarrollo y mantenimiento del software. Sin embargo, la sido constatado que estos modelos y estándares no dirigen adecuadamente sus enfoques a los procesos de test. En este sentido, se presentan, a continuación, tres modelos de evaluación y mejora de procesos de test:

Acercamiento a la gestión de pruebas (Test ManagementApproach, TMap)Modelo de Mejora del Proceso de test (Test Process Improvement, TPI)Modelo de Madurez del Test (Test Maturity Model, TMM)

Metodologías de Pruebas alineadas con procesos de desarrollo

Introducción


Metodologías de pruebas alineadas con procesos de desarrollo

TMapTPITMM


Metodologías - TMap

La metodología TMAP, está basada en cuatro piedras angulares:

Proceso de desarrollo relacionado con el modelo de ciclo de vida para las actividades de pruebas (L)Sólida Organización (O)Recursos e Infraestructura (I)Técnicas utilizables para varias actividades de pruebas (T)



Modelo de ciclo de vida de Pruebas



Técnicas


Infraestructura y Herramientas




Organización



TMapTPITMM


Metodologías - TPI

El modelo se compone de 20 Áreas Clave, cada una con diferentes niveles de madurez. Los niveles de todas las Áreas Clave están integrados en una Matriz de Madurez. Cada nivel está descrito por varios Puntos de Verificación. También forman parte del modelo algunas Sugerencias de Mejora que ayudan a alcanzar el nivel deseado.

El modelo TPI está basado en las mejores prácticas de la industria relativas a la mejora del proceso de pruebas. El modelo incluye guías prácticas para evaluar el nivel de madurez de pruebas de una organización así como los pasos para mejorar el proceso.

El propósito de tales mejoras podría ser alcanzar el nivel 3 del SEI-CMM ( Capability Maturity Model ).


Metodologías - TPINiveles

Puntos de VerificaciónLos requisitos para cada nivel están definidos en forma de Puntos de Verificación ( Checkpoints ): son preguntas que necesitan ser respondidas afirmativamente para poder calificar a dicho nivel. A partir de las listas de verificación se puede evaluar un proceso de pruebas y se puede determinar para cada Área Clave el Nivel alcanzado. A medida que se considera mejorada cada Área Clave, los Puntos de Verificación son acumulables: para poder clasificar para el nivel B, el proceso de pruebas necesita responder afirmativamente tanto a los Puntos de Verificación del nivel B como del nivel A.


Metodologías - TPIMatriz de Madurez

Todos los Niveles y Áreas Clave están interrelacionados en una Matriz de Madurez de Pruebas. Se ha concebido como una buena manera de expresar las prioridades internas y dependencias entre Niveles y Áreas Clave. No existe graduación entre Niveles: mientras que un proceso de pruebas no estéclasificado enteramente como nivel B, permanecerá en el nivel A.El propósito principal de la matriz es mostrar los puntos fuertes y débiles del actual proceso de pruebas y ofrecer una ayuda a la hora de determinar la prioridad de las acciones de mejora.

Optimizada (11-13)

Eficiente (6-10)

Controlada (1-5)


Metodologías - TPIAplicación del Modelo TPI

El proceso de mejora de pruebas es similar a cualquier otro proceso de mejora. La figura siguiente muestra las diferentes actividades de un proceso de mejora.



TMapTPITMM


Metodologías - TMM

El modelo TMM es un modelo de evaluación del proceso de test, guiado por el conjunto básicos de conceptos del CMM y compuesto por dos componentes principales: un conjunto deniveles de madurez y un modelo de evaluación.


Se describe cada nivel considerando los objetivos de la organización y la capacidad de test.La estructura de cada nivel (excepto el primero), consiste en un conjunto de objetivos de madurez soportado por sub-objetivos (o metas) de madurez que son alcanzados por las actividades, tareas y responsabilidades.

Las actividades y tareas representan las acciones que deben ser desempeñadas en cada nivel con el propósito de mejorar la capacidad del test

Se asignan responsabilidades para las actividades y tareas, a los gestores, a los desarrolladores y testers y a los usuarios y clientes

Metodologías – TMM: Conjunto de Niveles


Metodologías – TMM: Modelo de Evaluación

El Modelo de Evaluación consiste en un método que permite a la organización evaluar y mejorar sus procesos de test, basándose en un cuestionario de evaluación, un procedimiento de evaluación y el entrenamiento y criterios de selección del equipo de evaluación.Los objetivos de este componente son: proveer un esquema de evaluación de procesos de test de software y un fundamento para la mejora de dichos procesos a través de análisis de datos y planteamiento de acciones, así como contribuir con la ingeniería del proceso de software.


Índice

Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrolloUso de herramientas OpenSource Aspectos diferenciadores herramientas comerciales frente a open-sourceFactoría de pruebas


Uso de Herramientas Opensource

Gestión del Ciclo de PruebasAutomatización de Pruebas FuncionalesPruebas de CargaInspección de CódigoPruebas Unitarias


Registrar los problemas encontradosSeparar entornos y manejar configuraciones

Ensayando la implementación

Definir casos de prueba durante el análisis es una forma de documentar el producto

Es una forma de adelantarnos al problema

Testing independienteEl que desarrolla no pruebaMayor experiencia y concentraciónNadie está motivado para encontrar sus propios errores

Gestión del Ciclo de Pruebas - Algunas Claves

Documentar las pruebasCasos de prueba, estrategia de pruebas, ejecuciones …


Herramientas Opensource – Herramienta de Gestión

La gestión de las pruebas, requiere que la herramienta con la que se trabaje cumpla algunas características como:

Soportar en paralelo el desarrollo de la aplicación y la gestión de las pruebasTrazabilidad de requisitos a pruebas gestionando ejecuciones así como defectos y su resoluciónMejora la predictibilidad del proyectoAcceso en cualquier momento y lugar a pruebas e informes de ejecuciónControl centralizadoMejora la colaboración y comunicación entre equipos y proyectosPotencia la reutilización de objetos de pruebaAcceso protegido a elementos del proyectoSistema de informes

Como ejemplo, se muestra la herramienta TestLink.



TestLink, permite de manera intuitiva, la elaboración de casos de prueba, con los pasos a seguir para su posterior ejecución, así como de los resultados esperados, quedándose todo ordenado y accesible a través de un árbol de navegación.


Durante todo el ciclo de vida se pueden obtener métricas tanto del los casos de prueba generados como de estado de la ejecución de los mismos.



Herramientas Opensource – Automatización Pruebas Funcionales

Las herramientas de Automatización de pruebas funcionales cumplen el siguiente ciclo de trabajo:

Planificación de pruebas automáticasRegistro de las acciones de usuarioControl y verificación de los CheckpointsComprobación resultado esperado = resultado obtenidoGestión del mapa de interfaz de usuarioTesting modular y batch

Como ejemplo, tenemos la herramienta Selenium, que nos permite la operativa de trabajo descrita.



Primeramente, se graban las acciones del usuario sobre la aplicación, quedándose éstas recogidas en la aplicación para su posterior tratamiento, que se realizará modificando el código generadoPrácticamente la totalidad de las herramientas Opensource, trabajan solo sobre aplicaciones Web.



Los casos de prueba, pueden ser modificados para introducir puntos de control, pausas, verificaciones, etc.

La ejecución de los mismos se puede planificar, agrupando casos y programándolos.

Se obtienen informes sobre los resultados de las ejecuciones.


Herramientas Opensource – Pruebas de Carga

Las herramientas para la realización de pruebas de Carga, tiene las siguientes funcionalidades

Planificación de pruebas de cargaCreación de los escenarios de pruebaSimulación de n usuarios concurrentesAnálisis de resultados de ejecución de los distintos escenarios

A continuación podemos ver la operativa ejemplificada con la herramienta OpenSta



Para la ejecución del test, se introducen datos como número de usuarios, scripts que compondrán la ejecución y elementos a ser testados como % Cpu,memoria, etc...



Durante la ejecución de la prueba, se puede monitorizar todos los recursos que sean de nuestro interés.



Posteriormente a la ejecución, se pueden obtener tanto log como gráficas con las estadísticas de la prueba. Algunas de ellas son las de puntos de medida respecto del tiempo, puntos de medida respecto del número de usuarios, número de usarios activos, errores HTTP, etc


Las inspecciones del código tienen el objetivo de detectar aspectos que influyen en la calidad de éste:

Errores de ejecuciónMermas de rendimientoCódigo muertoRedundancia de códigoIncumplimiento de arquitecturaIncumplimiento de estándares técnicos a nivel de codificación.Mantenibilidad del código

Metodología de trabajo:Priorización: Se suele aplicar orientación al riesgo. Medición: Uso de herramientas de análisis. Se obtienen métricas de nivel técnico que permiten la detección de incumplimientos y/o deficiencias, cuyo conjunto se expresa en:Informes de auditoria.Plan de mejora. Informe de recomendaciones para la mejora.

Uso de Herramientas Opensource . Inspección de Código


Publicarversión

Nueva versión software

Se realiza la entrega de una nueva versión de software por parte del proveedor.

Integracióncontinua

Generacióninformes

Publicacióninformes

Notificación víamail

Generacióninforme SAC

Uso de Herramientas Opensource . Inspección de CódigoEntrega de una nueva versión



Generacióninformes




Publicarversión


El jefe de proyecto publica el entregable en el repositorio común CVS

Herramientas:• CVS:

Implementa un sistema de gestión de versiones.

Mantiene el registro de todo el trabajo y los cambios en la implementación de un proyecto, permitiendo la colaboración entre distintos desarrolladores.

Es un referente en software libre de gestión de versiones .

Uso de Herramientas Opensource . Inspección de CódigoPublicación de la nueva versión


El proceso de integración continua (automático) detecta la nueva versión en el repositorio y ejecuta un conjunto de tareas programadas

Herramientas:• Continuum v1.0.2:

Servidor de integración continua. Realiza tareas programadas sobre

proyectos basados en java. Alto grado de integración con Maven.

Generacióninformes



GeneraciónInforme SAC


Publicarversión


Proceso de integración continuaUso de Herramientas Opensource . Inspección de Código


Generacióninformes


GeneraciónInforme SAC


Publicarversión



Se notificará por mail, al conjunto de usuarios definidos, la nueva entrega.:

Jefe de proyecto.SAC.Etc.

Notificación vía mailUso de Herramientas Opensource . Inspección de Código






Publicarversión


Generacióninformes

Se generarán automáticamente los informes de calidad programados.

Herramientas:• Changelog v1.8.2• QALab v0.7.2• CheckStyle v2.5• JavaDoc Reporte v1.7• Jcoverage v1.0.9• Jdepend v1.5• NCSS v1.3• Pmd v1.6• FindBugs v0.9.2• File-Activity 1.5.2

Generación de informes automáticamenteUso de Herramientas Opensource . Inspección de Código


Generacióninformes



Publicarversión


Se publicarán de forma automática los informes generados en el portal de calidad



Herramientas:• Maven v1.0.2:

Herramienta para la gestión y comprensión de proyectos java.Estándar de mercado en el mundo free.Metodología XP.

Herramientas:• Apache v utilizada por explotación:

Servidor http referente del mercado.

Publicación de InformesUso de Herramientas Opensource . Inspección de Código


Generacióninformes

Nueva versiónsoftware

Publicarversión





El SAC generará un informe con los resultados de las inspecciones realizadas al código:• Resumen ejecutivo (dirección).• Detalle técnico (equipo técnico).

Generación de resumenUso de Herramientas Opensource . Inspección de Código


Responsableproyecto

Internet

CVSSAC

(entregas)

Continuum

Maven

Apache

Preexplotación

SAC

Desarrollo

GestiGestióónnversionesversiones

RecursosRecursosSACSAC

FrontalFrontal

Explotación

CVSdesarrollo

Equipodesarrollo

Internet

ArquitecturaUso de Herramientas Opensource . Inspección de Código


Herramientas Opensource – Pruebas Unitarias

El peso de la generación de las pruebas unitarias recae sobre el equipo de desarrollo.La responsabilidad del equipo de SQA es la de ejecutar el conjunto de pruebas unitarias, validar los resultados y medir el grado de cobertura de las mismas.El conjunto de pruebas unitarias proporcionadas por el equipo de desarrollo debe cumplir los siguientes normas:

Ejecutables de forma automática.Independencia del entorno.Autocontenidas.⌧Preprocesamiento.⌧Ejecución.⌧Postprocesamiento.

A continuación se muestra un ejemplo de la labor del equipo de SQA en un conjunto de pruebas basadas en Junit y Cobertura.



Junit es un framework ampliamente utilizado para la automatización de pruebas unitarias.

El equipo SQA ejecutarálas pruebas unitarias proporcionadas por el equipo de desarrollo obteniendo un informe con el resultado de la ejecución de las mismas.



Cobertura es una herramienta opensource que mide la cobertura de las pruebas por medio de la instrumentalización del código y la posterior medición de las líneas de código ejecutadas por el conjunto de casos de prueba unitarios.El equipo de SQA instrumentalizaría el código y posteriormente ejecutaría el conjunto de pruebas unitarias analizando los resultados.



A continuación se muestra una salida estándar de la herramienta:



Cobertura calcula la cobertura de las pruebas contabilizando:

Número de líneas de código ejecutadas.Número de ramas ejecutadas.

Adicionalmente Cobertura calcula la complejidad ciclomática (Mc-Cabe) de cada una de las clases.



La herramienta permite realizar drill-down para visualizar la cobertura de las clases pertenecientes a un determinado paquete

Y llegar al máximo detalle visualizando las líneas de código ejecutadas en una determinada clase



Esta herramienta permite al equipo de SQA validar el porcentaje de cobertura de las pruebas unitarias realizadas por el equipo de desarrollo, identificando módulos poco probados o no probados.Los resultados de la herramienta permiten ampliar el plan de prueba unitario con casos de prueba específicos que cubran el código no testeado.También permite identificar porciones de código “muerto” que no es posible ejecutar.


Índice

Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrolloUso de herramientas OpenSourceAspectos diferenciadores herramientas comerciales frente a OpensourceFactoría de pruebas


Aspectos diferenciadores Herramientas comerciales frente a Opensource

Ventajas OpenSource¡Coste licencias es nulo!Construidas con los mismos principios que las comerciales:⌧ Arquitectura⌧ Metodología/Técnicas

Extensibles/Integrables (Código abierto)En algunos casos y para ciertos entornos, ¡son más potentes que las comerciales!

Inconvenientes OpenSourceNormalmente sólo disponibles para entornos web/javaEntornos de desarrollo “espartanos”En ocasiones, lenguajes propietariosEn su desarrollo prima la funcionalidad básica frente a la avanzada y/o utilidades/gadgetsEl aprendizaje suele ser costoso⌧ Material de formación muy básico o inexistente⌧ No suele disponerse de guidelines metodológicos

Estabilidad/FiabilidadEl soporte suele ser una incógnita (comunidades de usuarios/desarrolladores). Normalmente es escaso o nulo



Ventajas ComercialesMultientorno: web/java, middleware, C/S, legacy (mainframe)Entornos de desarrollo⌧ IDE gráficos plenos de utilidades⌧ Lenguajes abiertos

Entornos de ejecución con herramientas de análisis, monitorización, diagnóstico, …Robustez y Escalabilidad⌧ Arquitecturas tolerantes a fallos

Metodología/Técnicas: El fabricante aporta las suyas propiasIntegradas ⌧ Por supuesto las de un mismo fabricante⌧ En muchas ocasiones, entre fabricantes

Integrables (mediante APIS)Herramientas de Reporting potentes⌧ Integradas con paquetes ofimáticos con su correspondiente plantillaje⌧ Dashboards ejecutivos (Web)

Soporte técnico solvente (¡cuesta, pero existe!)Inconvenientes Comerciales

Coste licencias. ¡Suele asustar!



Conclusiones:Empezar con opensource no es mala idea:

En entornos web/java exclusivamenteLas herramientas funcionanParte del conocimiento adquirido es reaprovechable.

¡Pero ojo, hay que tener en cuenta los costes!Hay un sobreesfuerzo asociado al uso de opensource con respecto a comerciales (la productividad no es la misma) que hay que tener en cuenta:⌧ Un proyecto grande o varios proyectos pequeños pueden

justificar la inversión en comercialesMigrar de opensource a comerciales tiene un coste de reciclaje técnico

Definitivamente, en algún momento tendremos que adquirir alguna herramienta comercial:

Por adecuación al entornoPor limitaciones en la funcionalidad de las opensourcePor necesidades de reporting avanzado¿Por capricho? ¿A quién no le gusta el Ferrari?


AutomatizaAutomatizaAutomatiza---cicicióóónnn

Reporte de Reporte de Reporte de IncidenciasIncidenciasIncidencias

Carga y Carga y Carga y EstrEstrEstrééésss

Pruebas Pruebas Pruebas ManualesManualesManuales

GestiGestiGestióóón de n de n de PruebasPruebasPruebas

Herramientas Comerciales


Índice

Introducción. Visión general del proceso de pruebas. Metodologías de pruebas alineadas con procesos de desarrolloUso de herramientas OpenSourceAspectos diferenciadores herramientas comerciales frente a OpensourceFactoría de pruebas


Factoría de Pruebas - Conceptos

Grupo dedicado que provee testing como un servicio compartidoEmplea un conjunto de personas que se especializan en uno o múltiples tipos de testing o uno o mas dominios de negocio o tecnológicos.Entre los roles de una Factoría de Pruebas se pueden incluir:

Definición de los procesos y estándares de testing a ser adoptados por los proyectosImplantación de los procesos y estándares definidosProvisión de personal cualificado y entrenado a los proyectosPlanificación y ejecución de testing para varios proyectos


Factoría de Pruebas- Tradicional vs FdP

Se aprovecha óptimamente las diversas habilidades a través de los diferentes proyectos

Posible duplicación de habilidades y entrenamiento a través de los diferentes proyectos

Se aprovechan los procesos de testing a través de los diferentes proyectos –Consistencia

Los procesos de testing son implementados inconsistentemente a través de los proyectos

Se dedica un pool de recursos de testing para uno o mas proyectos

Se dedican diferentes testers durante las diferentes etapas del proceso de testing o a través de diferentes proyectos

Se emplean tester especializados con habilidades y que han sido entrenados para realizar testing

Los desarrolladores se emplean como testers durante las últimas etapas del proyecto

Se contrata al equipo de test para múltiples proyectos basados en compromisos

Se contrata al equipo de test por proyecto, dependiendo de la disponibilidad de los recursos

Factoría de PruebasAcercamiento Tradicional


Factoría de Pruebas – Requisitos de una Factoría de Pruebas

Centro de pruebas externoProyectos de PruebasInterlocución a través del clienteCiclo de vida iterativo –incremental

Entregar código fuente

Entornos altamente emulables

Pruebas 80% caja negra


Ges

tión

de

Clie

ntes

Gestión de la configuración SW

Seguridad

Aseguramiento de la Calidad

Gestión de Pruebas

Hel

pD

esk

Factoría de Pruebas – Funcionalidad


Factoría de Pruebas – Operativa


Factoría de Pruebas – Perfil del Proveedor

Experiencia probada en:Trabajar (“testear”) en el entorno de negocio del ClienteTrabajar en formato Factoría de Pruebas, con todas sus implicaciones⌧ Comunicación⌧ Gestión del proceso⌧ Gestión de la Infraestructura⌧ Formación

Alcance de su experienciaTipos de TestEntornos de TestTesting basado en riesgoExperiencia en su dominio específico del negocioEmpleados propios y con experiencia en testing

Disponibilidad de equipamiento, infraestructura, herramientasFlexibilidad y adaptabilidadNiveles de servicio ofrecidos


Factoría de Pruebas – Composición del Equipo


Factorías de Pruebas focalizadas en el cliente

Equipo base + recursos bajo demandaDiferentes acercamientos

Focalizados en tipo de testing⌧ Web Testing, Load and Performance testing, LocalizaciónFocalizados en herramientasFocalizados en Tecnologías⌧ Web, .Net, Java, Cliente/Servidor, Mainframe

Mayores ventajas hacia nuestros clientes en términos de:

Competencias técnicasReutilización de infraestructuras, test wares...Retención de conocimientoOptimización de los procesos


Factoría de Pruebas – Que ha funcionado con los clientes

Desafíos inicialesJustificación de costos iniciales para el clienteFalta de sinergia a través de diferentes áreas de negocio del clienteSin certeza de por donde empezar y como procederConflictos entre estandarización del proceso y el ahorro del costo a través del outsourcing

Como los superamosFase Piloto/Pruebas de concepto (área de bajo riesgo)Establecimiento de un modelo compartido de servicios de testing,recursos del cliente y del proveedor trabajando muy cercaSe comienza en pequeño, llevando un área cada vez al modelo de Factoría de Pruebas.⌧Opción A: Se comienza con una evaluación, a través de las diferentes áreas

para analizar y recomendar estandarización de procesos⌧Opción B: Un área o aplicación en concreto, en base a las prioridades

existentesSe comienza a incrementar la carga de trabajo/proyectos/áreas a medida que la confianza va creciendo


Factoría de Pruebas – Flexibilidad bajo demanda

Mejorar el uso de los recursos internos optimizando los periodos de sobrecargaIntroducir su producto en el mercado mas rápidoArranque inmediatoAbsorber los retrasos y cambios repetitivos


Valor ObjetivoIndicadorCriticidad


>90%≤2 iteraciones

>90%≤20% nº de componentes instalados respecto a la planificación2


>90%≤10% nº de componentes instalados respecto a la planificación1

FASE DE IMPLANTACIÓN/PASO A PRODUCCIÓN


>90%≤40% sobre el total de pruebas en el plan de pruebas2


>90%≤20% sobre el total de pruebas en el plan de pruebas1

FASE DE PRUEBAS


=100%=10% requisitos no incorporados en la solución2


=100%=0% requisitos no incorporados en la solución1


FASE DE ANALISIS DISEÑO Y CONSTRUCCIÓN

Factoría de Pruebas – SLA: Acuerdo de Nivel de Servicio


Factoría de Pruebas – Conclusiones

Las Factorías de Pruebas son un concepto focalizado en el outsourcing estratégico del testingLas Factorías de Pruebas centradas en el cliente pueden ofrecer significativos beneficios ya que están enfocados a mejorar continuamente en base a la experiencia y el conocimientoEl valor del negocio del test outsourcing puede ser medido y mejorado a través de un programa de métricas consensuado


Ruegos y Preguntas

Test de caja negra basados en los requisitos y las

especificaciones funcionales

ValidaciónFuncional

Conjunto de pruebas dinámicas que aseguran el

comportamiento del sistema en determinados escenarios

Pruebas deCarga

Validación del diseño y facilidad de uso de los interfaces de usuario,

siguiendo los estándares de mercado

Test deUsabilidad

Validación, verificación y trazabilidad de requisitos y documentación funcional

InspeccióndocumentalRevisión de la seguridad de

las aplicaciones, principalmente web ante las vulnerabilidades conocidas

Revisión de la seguridaddel código

Automatización de las actividades de SQA: análisis

de código, ejecución de casos, reporte de defectos,

gestión de pruebas

Automatizacióndel Servicio

Revisión del diseño y codificación de las distintas capas: Interfaz de usuario,

datos e integración

Test deCaja Blanca


Gracias

la calidad del software y los procesos de testing

Documents