Este documento proporciona una introducción a las pruebas de calidad de software (QA) y cubre varios temas clave como: las diferentes categorías de pruebas como las pruebas unitarias, de aceptación y de regresión; herramientas comunes de QA como Jenkins, Selenium y TestNG; y un ejemplo de cómo se podría estructurar un proyecto de pruebas automatizadas con Selenium. El documento también explica conceptos como integración continua, pruebas de caja negra y blanca, y cómo QA debería involucrarse a lo larg

1. Guillermo Delgado
QA
Sobre mí
gdelgado@emergya.com
Guillermo Luis Delgado Vázquez
@willifog

2. Í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 Stress
6. Smoke test
7. Test de Aceptación
8. Pruebas de Regresión

3. Índice (2)
9. ¿Qué herramientas utilizo?
10. Redmine
11. Jenkins
12. Eclipse + Selenium WebDriver + TestNG
13. Ejemplo Proyecto Selenium
➢ Project Overview
➢ TestSet
➢ PageObject
➢ Properties File
➢ Acceptance/Regression Suite
➢ Reports

4. ¿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.

5. ¿Qué significa la “calidad”?
▶ ¿Qué piensan las personas? ▶ ¿Qué piensan las empresas?
¿Documentación?
¿Certificados?

6. 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.

7. 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.

8. ¿Cómo obtenemos esa calidad?

9. 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

10. 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.

11. ¿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.

12. ¿Qué pruebas hay?

13. ▶ 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

14. 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?

15. 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ódulos
al proyecto.

16. ▶ 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 de
ambos números.
Si alguien del equipo modifica esta función y
el test falla, sabremos que existe un bug antes
de que el fallo llegue a producción. Sin él, en un
proyecto 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.

17. 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

18. 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.

19. 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.

20. 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

22. ¿Que herramientas utilizo?

23. Redmine (1)

24. Redmine (2)

25. Redmine (3)

26. 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.

29. ¿ 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.

30. ¿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.

31. Ejemplo proyecto Selenium

32. Project Overview

33. Ejemplo de Proyecto Selenium

34. TestSet (1)

36. TestSet (2)

38. TestSet (3)

40. PageObject(1)

42. PageObject(2)

44. Factory(Users)

46. Properties File

48. Acceptance Suite

50. Regression Suite

52. Reports

53. Agradecimientos
Alejandro Gómez Morón
Oscar Castaño Calle
Jose Antonio Dorado Ceron
Antonio José Rodríguez Ríos

54. A vosotros por haber asistido!