Automatizacion de Testing.

Transcripción

Automatizacion de Testing.
“Automatizacion de Testing.” Logo@Copyright www.bstriker.com 1 Objetivos 1.  Compartir conocimiento adquirido en distintos proyectos con la comunidad de Testing. 2.  Generar un espacio donde se generen nuevas relaciones entre los participantes. (Francisco) 3.  Proveer herramientas de desarrollo profesional para los referentes de la comunidad. 4.  Facilitar teoría y fuentes de información académica. www.bstriker.com Historia del Testing •  Antes de 1956. Periodo orientado a debugging. En el ‘49 A.M. Touring es el precursor (Checking a large routine). •  Entre 1957 y 1978. Periodo orientado a demostración. •  Entre 1979 y 1982. Periodo orientado a destrucción. Myers -­‐ The Art of Software Testing. •  Entre 1983 y 1984. Periodo orientado a evaluación. (V,V&T). •  Entre 1985 y la actualidad. Periodo orientado a prevención. STEP (Systematic Test and Evaluation Process) www.bstriker.com ¿Por qué? • 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
Modelo de trabajo incorrecto. (Ágiles o Estructurados) Los objetivos del Testing no son claros. Se realiza más Testing basado en la experiencia de los testers. Testers sin formación o habilidad. No se cuenta con información relevante a las pruebas. No hay criterios claros de comienzo o fin de Prueba. Testing como cuello de botella. La infraestructura de Testing no se condice con la del ambiente productivo. Herramientas obsoletas o demasiadas herramientas. Equipo de Testing muy lejos. (¿Testers en Desarrollo o un área de Testing?) Proceso de trabajo incorrecto. Muchas otras razones www.bstriker.com Mejora Continua Modelos Básicos Otros modelos Comparativo Resumen Antes '56 57-­‐78 79-­‐82 (Myers) 83-­‐84 Debbuging Demo Evaluacion Destruccion (V,V &T) TESTING MODELOS DE DESARROLLO MODELOS DE MEJORA CONTINUA MODELOS GENERALES Cascada (Benignton -­‐ Royce) Prevención 92 Modelo 94 RUP V / W Primer Agil TMM -­‐ 90 STEP -­‐ 86 (3) (5) CTP (12) Deming PDCA Kaizen 85 …. TQM EFQM -­‐ 88 Six Sigma -­‐ 86 99 TDD TPI -­‐ 97 (4) (SOGETI) CMMi -­‐ SPICE -­‐ 02 '04 (6) Técnicas De Diseño También son técnicas de es_mación. Ayudan a generar escenarios de pruebas eficaces. Tienen el concepto de probar lo menos posible pero tanto como haga falta. Es donde mayor parte del esfuerzo de Tes_ng debe concentrarse. Miden la CALIDAD de un objeto de prueba desde dis_ntos puntos de vista. Cuando tiene calidad? - Exactitud (“accuracy”)
- Adecuación (“suitability”)
- Interoperabilidad (“interoperability”)
Atributos de calidad
para pruebas del
dominio
(funcionales)
- Seguridad técnica (technical security)
- Fiabilidad (“reliability”)
- Eficiencia (“efficiency”)
- Mantenibilidad (“maintainability”)
- Portabilidad (“portability”)
Atributos de calidad
para pruebas
técnicas
- Seguridad funcional (“functional security”)
- Usabilidad (“usability”)
- Accesibilidad (“accessibility”)
AUTOMATIZACION Principios Porque Automatizar?
- 
Permite ejecutar las pruebas sin posibilidad de “error”. Mayor
confiabilidad de los resultados.
- 
Optimizar el tiempo de ejecución de Pruebas.
- 
Cubrir mas configuraciones.
- 
Emular comportamiento del usuario final.
- 
Asegurar que las funcionalidades básicas no están afectadas por
cambios.
- 
Mejora en la comunicación porque hay un sistema que ejecuta.
Página 13
TECNICAS DE AUTOMATIZACION
- 
Record and Play (Human Scripting * Selenese *Cucumber)
- 
Scripting (Bash)
- 
Keyword Driven
- 
Data Driven
- 
Otros
Página 14
Herramientas mas utilizadas
- 
Calabash
- 
Selenium (distintas versiones)
- 
Jmeter
- 
Sikuli
- 
Fitness
- 
Apium
- 
Jameleon
- 
Telerik – HP – IBM – Blazemeter – Bstriker – Push To Test (sahi)
- 
http://www.xqual.com/qa/tools.html
Página 15
Cuando automatizar?
- 
La interfaz o la aplicación tiene un nivel de madurez suficiente como
para invertir esfuerzo en crear los scripts necesarios.
- 
A tener cuenta es el tiempo que lleva mantener los scripts.
QUE AUTOMATIZAR?
Escenarios complejos
Regresión de casos de pruebas
Comportamiento esperado o básico.
Página 16
Técnica de Implementación:
- 
Que escenario se desea automatizar y porque?
- 
Cuantas veces se ejecutara la prueba?
- 
Forma parte del camino básico?
- 
Tengo una descripción del comportamiento del usuario?
- 
Que tan difícil es emular el comportamiento?
- 
Se implementara la automatización desde frontend o backend?
Página 17
SELENIUM.
Página 18
Sikuli.
Página 19
Calabash.
Página 20
¡Muchas gracias! Logo@Copyright www.bstriker.com 

Documentos relacionados