Guillermo Delgado QA

Sobre mí

gdelgado@emergya.comGuillermo Luis Delgado Vázquez@willifog

Índice (1)1. ¿Qué es QA?2. ¿Cómo obtenemos esa calidad?3. ¿Cuándo se es QA?4. ¿Qué pruebas hay?

1. Test unitario: Pruebas de caja negra.2. Test unitario: Pruebas de caja blanca.

5. Test de Stress6. Smoke test7. Test de Aceptación8. Pruebas de Regresión

Índice (2)9. ¿Qué herramientas utilizo?10. Redmine11. Jenkins12. Eclipse + Selenium WebDriver + TestNG13. Ejemplo Proyecto Selenium

➢ Project Overview➢ TestSet➢ PageObject➢ Properties File➢ Acceptance/Regression Suite➢ Reports

¿Qué es QA?

▶ Definición:▶ QA significa Quality Assurance, o aseguramiento de la calidad. Se trata

de un conjunto de actividades de evaluación de las distintas etapas del proceso de desarrollo para garantizar que el producto final sea de calidad.

▶ El concepto de calidad se presta a múltiples interpretaciones, pero siempre implica que el software satisfaga las necesidades del cliente.

¿Qué significa la “calidad”?▶ ¿Qué piensan las personas? ▶ ¿Qué piensan las empresas?

¿Documentación?

¿Certificados?

Para nosotros:▶ Podemos decir que significa:

▶ Desarrollar.▶ Diseñar▶ Producir▶ Mantener

▶Un Producto que sea económico, el mas útil y siempre satisfactorio para el consumidor.

Punto de vista del cliente:▶ Grado en que un cliente

y/o usuario percibe que el producto software satisface sus necesidades.

Punto de vista de la industria:▶ Grado en que un

producto de software satisface su especificación de requerimientos.

¿Cómo obtenemos esa calidad?

Parte humana:▶ Aprendiendo de errores y

éxitos▶ Evaluando siempre cada

proyecto▶ Haciendo que todas las

partes se involucren (clientes, desarrolladores, testers)

▶ Sabiendo tus límites▶ Pidiendo ayuda cuando sea

necesario▶ Manteniendo una mente

abierta▶ Intentando siempre

aprender todo lo posible▶ Construir una “cultura de calidad” donde la calidad es vista como responsabilidad de

todos

Parte técnica:▶ Identificar casos de prueba.▶ Verificación de estándares y requerimientos.▶ Ejecución y documentación de pruebas. (Test case).▶ Identificar y clasificar los errores y/o defectos.▶ Crear un entorno de pruebas adecuado. ( Dev > CI > QA > Staging > Pre-

Production)▶ Diseño y ejecución integral de pruebas.▶ Realizar reportes estadísticos al final del proyecto.

¿Cuándo se es QA?

▶ La concepción tradicional relega a QA al final de todo el proceso.

Un tremendo error si pretendemos ser ágiles: conseguir que nuestra empresa pueda moverse rápido desarrollando poco a poco y contrastando las expectativas del cliente para subir a producción en pequeños sprints de dos semanas, por ejemplo. Y, por supuesto, ir rectificando rápidamente lo que no funciona o no acaba de encajar.

▶ ¿Al comienzo? ▶ ¿Mientras se desarrolla?▶ ¿Al final?

▶ Para conseguir los objetivos que plantean las metodologías ágiles, desarrollo y QA deben ir de la mano, integrados en el día a día. Cada equipo de desarrolladores debería contar con un encargado de QA que siga el proceso de desarrollo durante la concepción, análisis, desarrollo y, obviamente, verificación.

¿Qué pruebas hay?

▶ Test Unitario: Garantizar la calidad de módulos o partes aisladas.▶ Pruebas de Caja Negra.▶ Pruebas de Caja Blanca.

▶ Test funcionales, divididos en distintos grupos:▶ Acceptance/Smoke: Garantizar la calidad del core del proyecto.▶ Regression: Garantizar la calidad de la aplicación entera.▶ Progression: Garantizar la calidad del desarrollo actual (Release)

▶ Test de rendimiento: Garantizar la disponibilidad del sistema.

▶ Test Responsive: Garantizar que se cumplan las reglas de responsividad definidas.

Breve resumen

Pruebas de caja negra¿Qué son las pruebas de caja negra?▶ Son pruebas funcionales, dedicadas a “mirar” en el exterior de lo que se prueba.

Sabiendo solo la entrada y la salida.▶ Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten

completamente todos los requisitos funcionales de un programa. En ellas se ignora la estructura de control, concentrándose en los requisitos funcionales del sistema y ejercitándolos.

▶ No es una alternativa a las pruebas de caja blanca,  sino un enfoque complementario que intenta descubrir diferentes tipos de errores a los encontrados en los métodos de la Caja Blanca

▶ Las funciones del software son operativas

▶ La entrada se acepta de forma correcta

▶ Se produce una salida correcta ▶ La integridad de la información

externa se mantiene

▶ Funciones incorrectas o ausentes ▶ Errores en la interfaz ▶ Errores en estructuras de datos o

en accesos a bases de datos externas

▶ Errores de rendimiento ▶ Errores de inicialización y de

terminación

¿Qué pretenden demostrar?

¿Qué pretenden encontrar?

Pruebas de caja blanca.(1)▶ Tambien llamadas pruebas modulares ya que nos permiten determinar si un

módulo del programa esta listo y correctamente terminado.

▶ ¿De qué nos sirve una gran interfaz si, cuando voy a hacer una compra de entradas para el concierto de mi grupo favorito, el módulo de venta de entradas tiene un bug y no me permite comprar?

▶ La experiencia nos ha enseñado que los bugs son imposibles de evitar, y menos en procesos de Continuous Delivery donde hay nuevas versiones que refactorizan o incorporan nuevos módulosal proyecto.

▶ Los tests unitarios deben comprobar que una función que se ha programado, siempre debe funcionar igual.

Con este pequeño test, nos aseguramos que la función siempre nos devolverá la multiplicación deambos números.Si alguien del equipo modifica esta función yel test falla, sabremos que existe un bug antesde que el fallo llegue a producción. Sin él, en unproyecto de decenas de miles de líneas de código fuente lo más probable es que el bug no sea detectado hasta estar en producción.

Pruebas de caja blanca.(2)

Este conocido framework para PHP nos permite crear y ejecutar juegos de tests unitarios de manera sencilla.

Basado en la familia de frameworks xUnit constituye junto con alternativas como SimpleTest o phpt, los principales frameworks de pruebas unitarias en PHP.

Test de Stress▶ Las pruebas de performance permiten conocer y mitigar los riesgos

relacionados con el mal desempeño de las aplicaciones en los entornos de producción y realizar las correcciones necesarias antes de salir al mercado.

▶ Se cuantifica la capacidad de la infraestructura, se validan los requerimientos de performance, la escalabilidad de las plataformas y del sistema a probar.

▶ De esta manera, la empresa puede conocer qué cantidad de clientes simultáneos soporta su producto, con tiempos y datos razonables sobre la infraestructura y las plataformas propuestas.

▶ En general los objetivos de los test de Stress suelen ser mejorar:▶ Rendimiento▶ Escalabilidad▶ Estabilidad

Smoke test o pruebas de humo▶ Este tipo de pruebas son pruebas rápidas que buscan encontrar problemas graves (fuego

oculto) en el software recientemente modificado. El nombre viene de los sistemas electrónicos donde la prueba inicial es que no hay humo al conectar la fuente de energía.

▶ Las pruebas de humo buscan problemas críticos en la aplicación que hacen que no valga la pena validar otro tipo de pruebas. Preguntas como: ¿El sistema inicia correctamente? o ¿El menú principal se presenta correctamente?  caracterizan el objetivo de las pruebas de humo.

Test de aceptación▶ Los test de aceptación son aquellos destinados a determinar si los requisitos

de cierta funcionalidad han sido cumplidos, centrarse en que la parte funcional cumple las expectativas creadas al inicio del Sprint.

▶ El test de aceptación termina de definir el nivel de calidad de un software y le permite conocer al equipo de desarrollo qué tan bien supo interpretar los pedidos del cliente durante la gestación del proyecto.

Pruebas de regresión▶ Las pruebas de regresión son las pruebas que se ejecutan después de

un cambio en el sistema (nueva característica o solución a un bug). Su objetivo principal es validar que las características previas al cambio no se vean afectadas.

▶ Son las primeras candidatas a automatización pues deben repartirse periódicamente con cada uno de los cambios o actualizaciones

¿Que herramientas utilizo?

Redmine (1)

Redmine (2)

Redmine (3)

Jenkins ▶ ¿Qué es Jenkins?

▶ Jenkins es un servidor de integración continua, gratuito, open-source y actualmente uno de los más empleados para esta función.

▶ La base de Jenkins son las tareas, donde indicamos qué es lo que hay que hacer en un build. Por ejemplo, podríamos programar una tarea en la que se compruebe el repositorio de control de versiones cada cierto tiempo, y cuando un desarrollador quiera subir su código al control de versiones, este se compile y se ejecuten las pruebas.

▶ Si el resultado no es el esperado o hay algún error, Jenkins notificará al desarrollador, al equipo de QA, por email o cualquier otro medio, para que lo solucione. Si el build es correcto, podremos indicar a Jenkins que intente integrar el código y subirlo al repositorio de control de versiones.

▶ Desde Jenkins podrás indicar que se lancen métricas de calidad y visualizar los resultados dentro de la misma herramienta. También podrás ver el resultado de los tests, generar y visualizar la documentación del proyecto o incluso pasar una versión estable del software al entorno de QA para ser probado, a pre-producción o producción.

¿ Eclipse + Selenium WebDriver + TestNG ?

▶ Esta combinación nos proporciona bastantes cosas:▶ Programar test en Java, que interactúan con la aplicación web.▶ Permite hacer debug de los mismos.▶ Hacer capturas de lo que ocurre cuando un test falla.▶ Grabar un video de los test que se lanzan.▶ Crear un report en el que se visualizan los resultados de los tests.

¿Qué hace Selenium?▶ Un breve resumen sería lo siguiente:

▶ Selenium levanta un navegador Firefox, que según el test que se haya lanzado, simulará ciertas acciones sobre una aplicación web (clicks, scrolls, moverse a través de las páginas, seleccionar elementos, etc ) para comprobar que el comportamiento es el adecuado de acuerdo a unas pre y post condiciones que hemos programado.

▶ Si el test falla, mostrará donde ha fallado, y si se ha programado bien, se verá en que sitio ha ocurrido el error, por lo que será fácilmente averiguar el por qué de ese error.

▶ Con el uso de algunos plugins selenium puede hacer capturas en el momento en el que ocurre un error o grabar la ejecución entera de un test en video, por lo que al desarrollador le es mas fácil llegar al problema.

Ejemplo proyecto Selenium

Project Overview

Ejemplo de Proyecto Selenium

TestSet (1)

TestSet (2)

TestSet (3)

PageObject(1)

PageObject(2)

Factory(Users)

Properties File

Acceptance Suite

Regression Suite

Reports

Agradecimientos

Alejandro Gómez Morón

Oscar Castaño Calle

Jose Antonio Dorado Ceron

Antonio José Rodríguez Ríos

A vosotros por haber asistido!