Rational Comes to You 2008, Presentation by Walter Ariel Risi
1. IBM Rational Software Comes to You Buenos Aires 2008
Walter Ariel Risi, Grupo Pragma Consultores 1
2. No sólo de pruebas funcionales
vive el software … Calidad
Técnica y Automatización
Walter A. Risi, CQE, CSQE
Grupo Pragma Consultores
3. IBM Rational Software Comes to You Buenos Aires 2008
Hace algunos años …
Hablar sólo de invertir en
calidad era iniciar un debate!
Hoy... la situación ha cambiado
notablemente
(para bien)
Mayor conciencia y mayor
institucionalización
Las discusiones son sobre la forma y la
eficacia, no de fondo …
Walter Ariel Risi, Grupo Pragma Consultores 3
4. IBM Rational Software Comes to You Buenos Aires 2008
¿Cómo está el clima en la QA-landia local?
Funcionalidad
correcta Seguridad
Facilidad
de uso
Performance
Automatización
Escalabilidad
Facilidad de
Facilidad de extensión
mantenimiento
Walter Ariel Risi, Grupo Pragma Consultores 4
5. IBM Rational Software Comes to You Buenos Aires 2008
¿y las consecuencias?
Finalmente, los problemas aparecen …!
Al final del proyecto, o aún después
En la peor zona de la curva de costos !!
Muchos otros quedan, dejando costos
Los más graves deben
“ocultos”
solucionarse... con el
matafuegos
Baja productividad de usuarios internos
Mala imagen frente a clientes externos
Demoras y sobre-costos
Aplicaciones que caen en desuso
(frecuentemente, mayores que
Necesidad excesiva de recursos de
los de prevención)
hardware
Pueden afectar la imagen, la
¡Altos costos de mantenimiento y
confianza y, quizás, el negocio
envejecimiento prematuro!
Walter Ariel Risi, Grupo Pragma Consultores 5
6. IBM Rational Software Comes to You Buenos Aires 2008
Los típicos “porqué” …
“El hardware no alcanza”
“No hubo tiempo / plata”
“En desarrollo y en testing
“Se suponía que en desarrollo y testing andaba bien, pero en
andaba lento por el hardware, pero que producción empezó a funcionar
en producción iba a andar bien” lento”
“Faltó que la gente de
“¿Cómo pudo pasar?, si la tecnología hiciera el tuning”
aplicación fue testeada” (alguien de desarrollo)
“Los programadores nunca piensan
“Esto lo iba a probar <otro-que-
en la performance” (alguien de
no-soy-yo>” (todos a coro)
tecnología)
Walter Ariel Risi, Grupo Pragma Consultores 6
7. IBM Rational Software Comes to You Buenos Aires 2008
Revisando los “porqué” (I)
“No hubo tiempo / plata”
Versión 1: No estaba previsto
Versión 2
(variantes):“Pensamos en incluir
una prueba de performance “El hardware no alcanza”
pero...”
“Las mejoras de performance “Se suponía que en desarrollo y testing
estaban previstas al final pero...” andaba lento por el hardware, pero que en
Los aspectos no funcionales producción iba a andar bien”
son “secundarios”
El hardware, una explicación frecuente,
pero ¿es cierto siempre?
Si era un riesgo, ¿no debería haberse
validad oportunamente?
Walter Ariel Risi, Grupo Pragma Consultores 7
8. IBM Rational Software Comes to You Buenos Aires 2008
Revisando los “porqué” (II)
“En desarrollo y en testing andaba
bien, pero en producción empezó a “Faltó que la gente de tecnología
funcionar lento” hiciera el tuning”
“¿Cómo pudo pasar?, si la aplicación “Los programadores nunca
fue testeada” piensan en la performance”
Testing funcional no es testing “Esto lo iba a probar <otro-que-
técnico no-soy-yo>”
¿Cuáles son las
responsabilidades? ¿Quién
tiene los skills necesarios?
Por otro lado, se resuelve entre
todos
Walter Ariel Risi, Grupo Pragma Consultores 8
9. IBM Rational Software Comes to You Buenos Aires 2008
Algunos agravantes
adicionales …
Proveedores externos,
¿cuáles son los controles y/o
Complejidad creciente de los incentivos para que cuiden la
sistemas calidad técnica?
RRHH escasos, con alta rotación,
Tecnologías novedosas, etc. Aumenta la probabilidades de
momento de recambio tener problemas técnicos
Falta de madurez (en la
tecnología y en quienes las
usan)
Cambio de expectativas para
Costos en u$s de hardware,
el usuario
herramientas, etc.
Walter Ariel Risi, Grupo Pragma Consultores 9
10. IBM Rational Software Comes to You Buenos Aires 2008
¿Qué hacer? La recomendación
pragmática es …
¡ Mantenga los riesgos bajo control !
1. Clarificar y hacer explícitas las
necesidades
Aseguramiento y Control de la
2. Analizar riesgos anticipadamente
Calidad Técnica
3. Evaluar las posibles mitigaciones y su
costo/beneficio
… permite reducir los riesgos de
4. Definir una estrategia
fallas en la operación
5. Planificar adecuadamente
6. Utilizar las herramientas adecuadas
7. Ejecutar
Walter Ariel Risi, Grupo Pragma Consultores 10
11. IBM Rational Software Comes to You Buenos Aires 2008
Acciones de Mitigación
Revisiones Técnicas
Pruebas Técnicas
Revisiones
Inspecciones, revisiones, Pruebas de Rendimiento o
walkthroughs, ... Performance
De diseño, de código, etc. Pruebas de Volumen (Datos)
Internas o externas Pruebas de Carga / Estrés
(Concurrencia)
Además …
Pruebas de concepto
Estrategias de roll out
Walter Ariel Risi, Grupo Pragma Consultores 11
12. IBM Rational Software Comes to You Buenos Aires 2008
Los Top Tips de Calidad Técnica
Las Revisiones de Arquitectura Las Pruebas de Volumen son
son particularmente cost effective relativamente simples y disminuyen
Claves: deben ser oportunas y muchos de los riesgos
con la gente apropiada Claves: generar un conjunto de
Muy interesante: pueden atenuar datos “suficientemente” grande
problemas de RRHH
¡¡ No se puede probar
Las Pruebas de Carga/Estrés tienen una cierta performance de lo que no
complejidad, pero cuando el riesgo es alto... anda !!
Hardware, volumen, herramientas y expertise Si hay optimizaciones,
Claves: balance costo/beneficio y sponsor regresión funcional
facilitador
Walter Ariel Risi, Grupo Pragma Consultores 12
13. IBM Rational Software Comes to You Buenos Aires 2008
¿Cómo se prepara y ejecuta una
prueba de carga / stress?
1 Se identifican las situaciones de uso a probar: transacciones,
procesos del negocio, modo de uso, etc.
2 Se capturan y se “parametrizan” las transacciones
individuales
3 Se preparan los distintos escenarios a probar.
4 Se ejecutan los escenarios y se monitorea la performance y
los indicadores de uso de la infraestructura.
Optimización
5 Se analizan y se interpretan los resultados.& Tuning
Walter Ariel Risi, Grupo Pragma Consultores 13
14. IBM Rational Software Comes to You Buenos Aires 2008
Automatización de Pruebas
Funcionales vs. Pruebas Técnicas
En las segundas, se está midiendo la
capacidad de un recurso compartido (un
En las primeras, el testing se servidor, que atiende múltiples
hace con una óptica de transacciones, clientes, etc.) para funcionar
usuario final. en ciertas condiciones (carga, situaciones
Se simulan los impactos sobre anómalas).
la interfaz, como lo haría un
usuario real. Se simulan los impactos sobre el servidor,
los tiempos de cliente se descartan.
En el primer caso, se automatiza algo muy conocido, que se prefiere
no hacer manualmente para ganar eficiencia y/o efectividad.
En el segundo caso, se simula una situación potencial, para prevenir los
problemas antes de que sucedan.
Walter Ariel Risi, Grupo Pragma Consultores 14
15. IBM Rational Software Comes to You Buenos Aires 2008
Automatización de Pruebas
Funcionales + Pruebas Técnicas
Si bien son actividades muy diferentes en el fondo, existen
elementos que las emparentan …
Ambas usan “robots” para automatizar las pruebas (los automatizadores
de pruebas funcionales pueden automatizar pruebas técnicas)
Algunos pruebas no funcionales pueden complementarse mediante
herramientas de prueba funcional automática (por ejemplo, validar la
performance desde la óptica del usuario, hacer recorridos muy largos,
realizar misma prueba con diferentes browsers y validar portabilidad)
Finalmente, luego del tuning debe realizarse siempre una regresión, para
lo cual la automatización es una práctica clave.
Walter Ariel Risi, Grupo Pragma Consultores 15
16. IBM Rational Software Comes to You Buenos Aires 2008
Tendencias Esperanzadoras a
Observar y Replicar
Servicio de Pruebas Técnicas en
Factories de QA
Automatización Gradual de
Pruebas en Factories de QA
Planificación Temprana de
Pruebas Técnicas, desde el
inicio
Desmitificación de la
Automatización (no es sólo record
& play, no es para reemplazar
testers, no es para eliminar el
Aceptación del Software
testing)
Incluyendo Pruebas Técnicas
Walter Ariel Risi, Grupo Pragma Consultores 16
17. IBM Rational Software Comes to You Buenos Aires 2008
Conclusiones
Prevenir o padecer
Énfasis en tareas tempranas
La falta de Calidad Técnica Correcto balance: la prueba
tiene su costo “ideal" quizás no sea
Importantes pero dispersos conveniente, pero lo peor es no
No hay que ignorar los hacer nada
(mayores) riesgos no Planificar adecuadamente
funcionales
Es necesaria una visión global
La automatización de pruebas Para evaluar los costos de la falta de
es otro paso más allá del calidad y para resolver los problemas
testing funcional (Desarrollo + Tecnología + QA + ...)
Es distinto a las pruebas técnicas,
pero es complementario y tiene
características comunes.
Walter Ariel Risi, Grupo Pragma Consultores 17
18. IBM Rational Software Comes to You Buenos Aires 2008
¡MUCHAS
GRACIAS!
Walter Ariel Risi, Grupo Pragma Consultores 18