Automatización de Pruebas de Software Openbot Automatización de Pruebas de Software

¿Qué es calidad en el software? Openbot Introducción ¿Qué es calidad en el software? El grado en el que un sistema, componente o proceso cumple con los requisitos especificados. El grado en el que un sistema, componente o proceso cumple con las necesidades o expectativas del cliente o usuario. (IEEE Std. 610.12-1990)

¿Qué son pruebas de software? Openbot Introducción ¿Qué son pruebas de software? Es la acción de operar un sistema, componente o proceso bajo condiciones especificadas, observando o registrando los resultados, y haciendo una evaluación de algún aspecto del sistema o componente. (IEEE Std. 610.12-1990)

Openbot Proceso manual Las pruebas manuales pueden encontrar defectos en una aplicación de software. Adicionalmente, este puede no ser efectivo encontrando cierta clase de defectos (rendimiento, concurrencia, estrés) . Siempre mantienen su costo, pues es necesario realizar constantemente las mismas tareas en las mismas condiciones por cada cambio en el producto.

Openbot Proceso automático La automatización de pruebas es usada para controlar la ejecución de pruebas, funciona básicamente comparando los resultados reales con los resultados previstos Comúnmente, consiste en la automatización de un proceso manual previamente establecido.

Pruebas No Funcionales Pruebas de Concurrencia Pruebas de Carga Openbot Que tipo de pruebas automatizar Pruebas No Funcionales Pruebas de Concurrencia Pruebas de Carga Pruebas de Estrés Pruebas de Compatibilidad Pruebas Funcionales Pruebas de Proceso Pruebas de Sistema Pruebas de Regresión Tomado automatización de pruebas GreenSQA

Automatizar el 100% de las pruebas no es una meta realista. Openbot Que Funcionalidades automatizar? Automatizar el 100% de las pruebas no es una meta realista. Funcionalidades de uso frecuente en la preparación de datos de pruebas. Funcionalidades especificas que demandan gran esfuerzo en el proceso de pruebas. Funcionalidades relativamente estables en su interfaz grafica. Funcionalidades con índice de densidad de errores relativamente alto. Funcionalidades de impacto a otros procesos del software. Tomado automatización de pruebas GreenSQA

Openbot Algunos Beneficios de la automatización Automatizar tareas mas repetitivas dejando mas tiempo para aquellas que necesiten mas atención. Diseñar mas casos de pruebas automáticos. Incrementar la cobertura en el proceso de pruebas. Incrementar las pruebas de configuración de datos. Asegurar la reutilización de pruebas. Por la no intervención humana, la ejecución se puede realizar en diferentes ambientes y en cualquier horario, lo que resulta en menores costos. Tomado automatización de pruebas GreenSQA

Openbot ¿Qué es realmente la automatización de pruebas? “Test Automation is Software Development. This principle implies that much of what we know about writing software also applies to test automation.” Dale H. Emery

Openbot ¿Qué es realmente la automatización de pruebas? “Much of the cost of software development is maintenance changing the software after it is written. This single fact accounts for much of the difference between successful and unsuccessful test automation efforts.” Dale H. Emery

Openbot ¿Qué es realmente la automatización de pruebas? “I’ve talked to people in many organizations that attempted test automation only to abandon the effort within a few months. When I ask what led them to abandon test automation, the most common answer is that the tests quickly became brittle and too costly to maintain.” Dale H. Emery

Openbot ¿Qué es realmente la automatización de pruebas? “But some organizations succeed with test automation. Don’t they experience maintenance costs, too? Of course they do. An important difference is that where unsuccessful organizations are surprised by the maintenance costs, successful organizations expect them.” Dale H. Emery

Openbot Probar aplicaciones GUI Para que puede servir en el producto SmartFlex Probar aplicaciones GUI Probar código en base de datos ORACLE (incluyendo PLSQL) Cuando existan casos de pruebas reducir su modificación por cambios en el diseño de la funcionalidad. Brindar la posibilidad que cualquier persona (desarrollor, personal de pruebas o diseñador ) pueda escribir los casos de prueba.

Openbot Para reutilizar los casos de prueba ya construidos. Para que puede servir en el producto SmartFlex Para reutilizar los casos de prueba ya construidos. Soportar buenas practicas de pruebas: unidad, regresión (lo que no ha sido modificado) y desarrollo orientado a pruebas. El caso de prueba pasa de ser un documento en texto a ser algo vivo, que puede ser ejecutado. Ayuda a tener un estándar en la interfaz gráfica. Ayuda en el análisis de procesos, rendimiento en ejecutables, comparación de ambientes. Ejecutar pruebas en horario de menor uso del hardware.

Openbot What's Robot Framework? Herramientas utilizadas – Robot Framework What's Robot Framework? Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development (ATDD). It has easy-to-use tabular test data syntax and utilizes the keyword-driven testing approach. Robot Framework is open source software released under Apache License 2.0. Its copyrights are owned and development supported by Nokia Siemens Networks

Openbot Herramientas utilizadas - Sikuli What's SIKULI? Sikuli is a visual technology to automate and test graphical user interfaces (GUI) using images (screenshots). Sikuli Script automates anything you see on the screen. Sikuli Script and Sikuli IDE are both released under the MIT License.

Openbot Integración de herramientas Sikuli y Robot Framework Test Data System Under Test Test Tools Test Libraries Robot Framework Test Data Application interfaces Test library API Test data syntax Sikuli Sikuli Scripts SmartFlex Openbot

Openbot Integración de herramientas Sikuli y Robot Framework Al tener los datos de prueba independientes, es posible reutilizarlos en otros escenarios o ejecutar las mismas pruebas usando información diferente

Openbot Integración de herramientas Sikuli y Robot Framework Provee el soporte para diseñar y ejecutar los casos de pruebas, adicionalmente facilita el análisis de datos como resultado de las pruebas en diferentes formatos de salida.

Automatizar las pruebas GUI usando imágenes. Openbot Integración de herramientas Sikuli y Robot Framework Automatizar las pruebas GUI usando imágenes.

Openbot Requerimientos - prueba concepto 1 Pruebas realizadas – prueba concepto 1 Requerimientos - prueba concepto 1 Abrir y cerrar opciones del menú de SmartFlex Más de 1200 opciones de menú Muchas de las opciones de la aplicación no son ejecutadas directamente desde el menú, gran cantidad están configuradas como parte de procesos de Presentación de Información (PI), esto exigía poder cargar y navegar los menús de los PI. Para análisis posterior, crear un reporte de las formas que fallaron, el tipo de falla, tiempos de ejecución y una imagen de la pantalla. Debe tener la capacidad de identificar la ventana abierta sin usar imágenes. Manejar tiempos de espera para la opción ejecutada, tanto desde el menú como desde el PI, si el tiempo de espera en la ejecución es mayor al esperado, la forma es marcada con error. Recuperación de fallas, en caso que la forma o el menú principal se cierren, la prueba no se debe detener.

Openbot Resultados - prueba de concepto 1 Pruebas realizadas – prueba concepto 1 Resultados - prueba de concepto 1 Abrir y cerrar opciones del menú de SmartFlex Formas ejecutadas en total 814, ejecutadas con error 173 (fueron excluidos los Procesos en Batch por el error SAO148802). Abrir y cerrar las 814 opciones toma un tiempo cercano a 5 horas. Encontrado un error en el ejecutor de Procesos en Batch (PB), reportado en el SAO 148802. La prueba fue codificada en 354 líneas (incluye comentarios y líneas vacías). Es posible ejecutar (abrir/cerrar) todas las opciones del menú, incluyendo las opciones que se encuentran agrupadas en los PI.

Openbot Resultados - prueba de concepto 1 Pruebas realizadas – prueba concepto 1 Resultados - prueba de concepto 1 Abrir y cerrar opciones del menú de SmartFlex

Openbot Resultados - prueba de concepto 1 Pruebas realizadas – prueba concepto 1 Resultados - prueba de concepto 1 Abrir y cerrar opciones del menú de SmartFlex

Openbot Requerimientos - prueba concepto 2 Pruebas realizadas – prueba concepto 2 Requerimientos - prueba concepto 2 Crear clientes, contratos y buscar cada cliente por identificación en el CRM La información del cliente y contrato viene en un archivo texto separado por “|” (formato CSV creado en Excel)

Openbot Requerimientos - prueba concepto 2 Pruebas realizadas – prueba concepto 2 Requerimientos - prueba concepto 2 Crear clientes, contratos y buscar cada cliente por identificación en el CRM Es necesario crear los siguientes registros: Cliente Contacto Dirección Contrato Si en el archivo no contiene identificación del cliente, se debe generar una aleatoria. Si la dirección no existe, se debe crear una para la ubicación geográfica dada. Registrar individualmente cada uno de los tiempos de la prueba, crear cliente, buscar cliente en el CRM, etc.

Openbot Resultados - prueba de concepto 2 Pruebas realizadas – prueba concepto 2 Resultados - prueba de concepto 2 Crear cliente, contratos y buscar cada cliente por identificación en el CRM Encontrado errores en los API de creación de cliente y creación de contrato, reportado en el SAO 151357. La prueba fue codificada en 175 líneas de código (incluye comentarios y líneas vacías). Fue posible establecer que el ambiente de PRUACT5 (Cablevision) era 5 veces más lento que el ambiente de calidad CALID76, el DBA hizo los cambios necesarios para mejorar el ambiente (aumento de memoria). Es posible medir las ejecuciones de cada una de las pruebas (para detalles ver siguientes diapositivas).

Openbot Pruebas realizadas – prueba concepto 2 – análisis de resultados

Openbot Pruebas realizadas – prueba concepto 2 – análisis de resultados

Característica funcional Openbot Propuesta - Estructura de casos de prueba Funcionalidad Modulo Característica funcional Caso de uso Ejecutable Caso de prueba

Demostración Banco de direcciones En vivo Banco de direcciones Diseñadas y construidas pruebas para: PLSQL (10 casos de prueba) Componente de ingreso de direcciones de producto (GUI) (18 casos de prueba) En total se tienen 28 casos de prueba con 72 escenarios diferentes El proceso manual para probar los 28 casos es de 7 horas, incluye preparación de datos (15 minutos por caso). El proceso automático se ejecuta en aproximadamente 6 minutos, con la ventaja que puede ser ejecutado por el desarrollador (13 segundos por caso).

Openbot Resultados de terceros Cantidad de casos de prueba Tipo Tiempo Tiempo por caso de prueba 160 Manual 40 horas 15 minutos 768 Automático 8 horas 37.5 segundos

Automatizadas algunas pruebas Otros resultados Empresa usando Visual Studio con Oracle/SQL Server 2 versiones por año Versión Cantidad de errores Comentario 1.0 353 2.1 324 3.0 500 4.0 361 Automatizadas algunas pruebas 5.0 11 Tercer ciclo de pruebas ejecutados (son 7 ciclos), se hacen 2 compilaciones/pruebas diarias Los desarrolladores no pueden modificar los casos de prueba automáticos, solo el grupo de calidad propone e implementa los casos. El desarrollador debe esperar el CI de la mañana o de la tarde para ver el impacto de los cambios.

“Empieza tu camino, pensando en el final.” Autor desconocido Openbot

Pero antes debemos conocer ¿Dónde estamos?

Openbot ¿Cómo construimos nuestro producto?

Openbot ¿Una vez ensamblado que pruebas de ruta se hacen?

Continuos integration Openbot Plataforma testbot Openbot Continuos integration buildbot

Openbot Continuous integration “La integración continua (continuous integration) consiste en la compilación y ejecución de las pruebas de todo un proyecto, lo más a menudo posible para así poder detectar fallos cuanto antes” Wikipedia

Openbot Alertas tempranas de código incompatible o no impactado Algunas ventajas de la integración continua Alertas tempranas de código incompatible o no impactado Alertas tempranas de cambios conflictivos Retroalimentación inmediata a los desarrolladores acerca del impacto del código modificado en la calidad, funcionalidad o en el sistema en general

Openbot Algunas ventajas de la integración continua Los desarrolladores pueden detectar y solucionar problemas de integración de forma continua, evitando el caos de última hora cuando se acercan las fechas de entrega Monitoreo frecuente de las métricas de calidad del proyecto El efecto de encontrar y corregir errores en las fases iniciales de desarrollo, permite ahorrar tiempo y dinero durante la vida útil de un proyecto

Infraestructura de integración continua Primera fase Pruebas GUI Pruebas PLSQL Windows 7 64bits Windows 7 32bits Servidor Integración Continua DB calidad SmartFlex 7.7

Infraestructura de integración continua Segunda fase Servidor Integración Continua Windows 7 64bits Windows 7 32bits DB de Pruebas del robot Windows 8 32/64 bits

Entregable de producto Openbot Certificación de producto testbot Unidad/regresión buildbot Integración continua Certificación de producto Ambientes: cliente/servidor (HPUX, LINUX, AIX, etc.) Regresión Escalabilidad/Rendimiento Estabilidad Seguridad Escenarios (Actualización/Instalación) Licenciamiento Entregable de producto setup.exe

Openbot Conclusiones La automatización no es una “bala de plata” que resuelva todos los problemas. Siempre se necesitarán pruebas manuales. La automatización inicialmente es costosa, a largo plazo es barata. Las pruebas manuales son costosas, y siempre mantienen su costo. La automatización es limitada a un alcance dado. Debe existir un balance entre pruebas automáticas y manuales.

“Este es un pequeño paso para Open…”

Gracias!