Estrategia de automatización en aplicaciones legadas

© 2015 Nunsys

Estrategia de automatización de aplicaciones legadas

4 de mayo 2015

Estrategia de automatización en aplicaciones legadas

¿Quién esta haciendo esto?


El desarrollo de sw en la actualidad

• Software que cumpla las expectativas del cliente

• Entregas de valor frecuentes con la máxima funcionalidad posible

• Con la máxima calidad posible

• En el menor tiempo posible


Beneficios

• Reduce el tiempo de testing manual

• Aumenta la calidad del software

• Permite entregas parciales de sw sin riesgos

• Aumenta la confianza


¿Qué es la automatización?



BDD




• Desconocimiento – curva de aprendizaje

• Falta de arquitectura

• Mantenibilidad del código

• 100% Cobertura de código

¿Por qué fallan los proyectos de automatización?



¿Por qué fallan los proyectos de automatización?

• Desconocimiento – curva de aprendizaje (20%)

• Falta de presupuesto(17%)

• Falta de tiempo (37%)

• Herramienta incorrecta (11%)

• 100% Cobertura de código (Automatizar todo, todo y todo)

• Falta de arquitectura

• Mantenibilidad del código

• No integrado dentro del desarrollo de sw


¿Seguro que con una herramienta basta?

¿Qué debemos automatizar y que no?

¿Qué debemos automatizar antes?

¿Qué herramienta utilizo?

¿Cuál es el coste de automatizar?

¿Cuál es el retorno de inversión de la automatización?

¿Cómo puedo medir el avance de la automatización?


Tranquilos………………


Estrategia

• Objetivos

• Planificar

–Qué

– Cuanto

– Cuando

– Cómo

• ROI

• Medir evolución

• Al proceso de desarrollo

• Al proceso de testing

• A la planificación y su calendario

• A la tecnología

• A la criticidad de la aplicación

Adaptada

© 2015 Nunsys

Caso real


El caso que vamos a presentar pertenece a una empresa del sector servicios. Dicha empresa

dispone de un departamento de IT con un equipo de desarrollo propio. Dicho equipo se

encarga de mantener varios activos software.

El activo sujeto al caso de éxito es una aplicación de escritorio instalado en 200 puestos de

trabajo y que es utilizado por 300 personas.

Caso real


o Se liberara una versión a producción cada tres semanas

o Las versiones a producción salen con muchos bugs

o Cada versión de producción supone al menos dos hotfixes

o El 35% del tiempo de los desarrolladores en arreglar bugs

o Time to market elevado dada la poca mantenibilidad del código y el tiempo empleado en test de regresión

o Riesgo elevado de errores por la falta de Tests. Alto coste de impacto

o Aplicación sin Tests automatizados

o Sin proceso de testing establecido

Situación


Responder a…..

¿Qué debemos automatizar y que no?

¿Qué debemos automatizar antes?

¿Qué herramienta utilizo?


¿Cuál es el retorno de inversión de la automatización?

¿Cómo puedo medir el avance de la automatización?


¿Qué debemos automatizar?

No se puede automatizar todo

• El tiempo es finito

• El presupuesto es finito

• Es costoso llegar al 100%

• Hay casos que no se pueden automatizar


¿Qué debemos automatizar?

Automatizaremos todo aquello que:

• Reduzca el coste de los test de regresión manuales

• Aumente la eficiencia de las pruebas

• Aumente la calidad del producto

• Sea imposible o muy costoso hacerlo manualmente


¿Por donde empiezo a automatizar?

• ¿Por lo más usado?

• ¿Por lo mas crítico?

• ¿Por lo que tiene más errores actualmente?


Solución propuesta

Mitigación Estabilización Integración


Risk Based Testing

o pruebas basadas en riesgos, que otorga la mayor prioridad a la ejecución de éstas en aquellas aplicaciones y procesos con mayor riesgo para el negocio en el caso de producirse un fallo en Producción

El verdadero valor de las pruebas es contribuir a que el software más crítico para el negocio sea, por consecuencia, también el más fiable y robusto.

Se entiende como Riesgos del Producto (quality risk) a aquellos eventos que podrían afectar la aceptación del sistema y/o a problemas potenciales que pueden afectar la calidad del producto que está siendo entregado al cliente o usuario final.


¿Cómo medimos el riesgo de la aplicación?

Para cada caso de uso mediremos el riesgo del fallo determinando:

• Frecuencia de uso

• Probabilidad de error

• Impacto que produce un error

Hagamos una evaluación de riesgos….de los casos de uso


Evaluar el riesgo de los casos de uso

Para el cálculo del riesgo utilizamos las siguientes consideraciones:

o Suponemos un número de casos de uso en la aplicación

o Utilizando la ley de Pareto realizamos una distribución de los casos de uso según su relevancia

o Utilizando la ley de Pareto realizamos una distribución de los casos de uso según su riesgo

o La disminución del riesgo se determina por la cantidad de casos de uso automatizados o testeados


Ejemplo

Distribución por Relevancia Relevancia Distribución por relevancia Núm Casos según relevancia

20%

Críticos 5% 5

Importantes 15% 15

80 %

Medios 35% 35

Bajos 45% 45

Mitigación de Riesgo Relevancia % Mitigación por

caso testeado

50% Críticos 10,00%

30% Importantes 2,00%

15% Medios 0,43%

5% Bajos 0,11%


Objetivo

o Implantación de un proceso de testing basado en la contención de riesgos

o Automatización de pruebas de aceptación del núcleo de la aplicación para mitigar los riesgos

o Revisión e implantación de técnicas de prevención de errores en el ciclo de desarrollo de software.

Mitigación Estabilización Integración


Etapa de mitigación

o El primer frente será determinar los casos de uso de la aplicación y realizar una evaluación de riesgos sobre dichos casos de uso de la aplicación.

o El segundo frente es definir una estrategia para garantizar la calidad de los entregables futuros.

Una estrategia a corto plazo donde ejecutemos los test funcionales críticos

Una estrategia a medio / largo plazo de automatización de test de regresión.


Pirámide de automatización


¿Cuánto debemos automatizar?

• Coste

• Presupuesto

• Riesgo aceptable



• Analizar un caso

• Diseñar un caso

• Preparar un caso

• Ejecutar un caso

• Mantener un caso

• Coste de infraestructura

• Coste de oportunidad

• Coste de las licencias

• Aprendizaje


¿Cuándo recuperaré la inversión?

Beneficios Tangibles

• ¿Nº errores detectados por automatización?

• Tiempo ahorrado en testing manual

• Aumento de productividad = Reducción del tiempo de arreglar bugs

Beneficios intangibles

• Aumento cobertura

• Reducción time to market

• Reducción del riesgo de la aplicación


Método coste de un bug

Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute)


Método de Coste Calidad

Costs of conformance es el coste de conformar la calidad del producto

Tareas como revisiones de requerimientos, unit testing => Prevención + Detección

Costs of nonconformance es el coste de arreglar bugs y retesting


Método Mitigación de riesgo

• ¿Podemos estimar el dinero que cuesta tener parado el sistema un hora?

• ¿Cuál es la probabilidad de que suceda?

• ¿Cuánta probabilidad mitigo si automatizo?


Indicadores -¿Cómo sabemos que lo estamos haciendo mejor?

1

2

Defect Removal Efficiency DRE%Errores detectados antes de release

PRODUCTIVIDADMidamos coste por caso de uso

3 RENTABILIDADCómo afecta a la rentabilidad de los proyectos

3 RIESGO MITIGADOCómo aumenta/disminuye el riesgo de la aplicación



“En aplicaciones con una deuda técnica muy alta se puede obtener un

gran retorno de inversión si automatizamos test de interfaz con la

funcionalidad más crítica”


Desmitificando las pruebas de interfaz

o Son sensibles a los cambios de interfaz

o Necesitas un conocimiento alto de programación

o Alto coste de preparación

o Muchas herramientas para testear

o Son difícilmente reutilizables


Etapa de estabilización

• Estabilizar la calidad de los entregables implantando una metodología de testing tradicional

• Determinar los casos de uso de la aplicación no analizados en la etapa anterior

• Alargar 2/3 días cada iteración (solo para testing tradicional)

• Seguir automatizando……

• El objetivo es reducir el periodo de QA al mínimo posible en varias iteraciones.


Etapa de incorporación al proceso

• Esta etapa incorporaremos el proceso de testing dentro del ciclo de desarrollo desoftware para ello proponemos aunar el análisis de las nuevas funcionalidades con suevaluación de riesgos basando este análisis en casos de uso.

• Cada caso de uso además de representar la solución al problema debe seguir la guíapropuesta por especificación por ejemplos en la cual añadiremos los criterios deaceptación de dicho caso.

ERSCRITERIOS

ACEPTACIONRisk Based

TestingERS/RBT


Muy bonito pero ¿Cómo lo hacemos?

ERS / RBTPLAN DE QA

PLAN

DEVOPS

PLAN DE

DESARROLL

O

Crear Infraestructura

Proveer Entorno test Paso a producción


Factores clave en la automatización

o Establecer objetivos claros y medibles

o Apoyo de la dirección

o Rentabilidad – ROI

o Equipo formado

o Conocimiento de la aplicación a testear

o Realizar Tests con bajo coste de mantenimiento

o Testear lo antes posible y frecuentemente

o Seleccionar la/s herramientas adecuadas