El documento presenta una introducción a las cápsulas de información sobre testing y describe cómo estas cápsulas brindan conceptos de testing de forma breve y concisa. Explica que las cápsulas están dirigidas a testers y otros miembros de equipos de desarrollo para profundizar sus conocimientos de testing de una manera incremental. Además, presenta el modelo del oráculo y cubre conceptos como entradas, resultados esperados y comparación, los cuales son fundamentales para el diseño de pruebas.

2.
Cápsulas de Testing
Pasos hacia un equipo integrado
Juan Gabardini
Cápsulas de Testing v0.2 2 / 17

3.
Introducción 4
Cápsulas de información 4
¿Para quién? 4
¿Cómo usar las cápsulas? 5
Próximas Cápsulas 5
Modelo del Oráculo 6
¿Cómo lo hago ahora? 6
Oráculos (Oracles) 6
Entradas (Input) 6
Resultados esperados (Expected) 7
Comparación 7
Actividades 8
Conclusiones 8
Referencias 8
Preparacion Datos 9
¿Cómo lo hago ahora? 9
Generación de datos 9
Estado conocido 10
Actividades 10
Pruebas Diagnósticas 11
¿Cómo lo hago ahora? 11
Las pruebas diagnósticas 11
Confiabilidad 12
Actividades 12
Arquitectura de prueba automática 13
¿Cómo lo hago ahora? 13
Para qué explicitar una arquitectura 13
Los usuarios 14
Los componentes 14
Conclusiones 16
Actividades 16
Cápsulas de Testing v0.2 3 / 17

4. Introducción
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a
building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders,
cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty
meal, fight efficiently, die gallantly.
Specialization is for insects.
Robert Heinlein
Cápsulas de información
Hace años, cuando empecé a estudiar inglés, en el libro aparecían cápsulas de información cultural que
agregaban contexto a las frase y vocabulario usado. Eran pequeños cuadros de textos al costado del texto
principal.
Mi intención es que este material permite incorporar conceptos de testing, en forma breve y concisa, en el
momento en el que aparece la necesidad.
Las cápsulas de información de prueba son una manera incremental de incorporar conceptos a partir de
ejemplos del equipo o externos. Pueden servir como guía para realizar círculos de aprendizaje en el equipo
de desarrollo o para profundizar conocimientos en comunidades de práctica.
¿Para quién?
Dentro de los equipos de desarrollo ágil de software esperamos colaboración entre los miembros sin una
separación tajante de tareas por roles. Para ello es necesario que los miembros del equipo tengan un
conocimiento mínimo de las especialidades necesarias para la construcción del producto. A esto se llama
el perfil T.
Perfil T​ (​T-shaped skill/person​): Un especialista puede aportar en un equipo sólo en su ámbito de
especialización A eso se le llama un ​Perfil I​. Un generalista puede aportar en todas las facetas de
la construcción, pero no tiene conocimiento profundo de ningún tema.
Testers​: Para las personas que dentro del equipo se especializan en
pruebas este material es una forma de incorporar, profundizar y ejercitar
su conocimiento.
Otras​: Para otras personas es una manera de incorporar el
conocimiento mínimo que les permita colaborar y realizar actividades
relacionadas con la prueba.
Cápsulas de Testing v0.2 4 / 17

5. ¿Cómo usar las cápsulas?
Este material está siendo utilizado en procesos de aprendizaje internos y también en encuentro
comunitarios. En ambos casos se toma una cápsula y se dedica 30-60 minutos. Se repasan los conceptos
(15 minutos) y luego se aplican los mismos siguiendo los ejercicios propuestos en la cápsula o en un caso
real que tenga el equipo en ese momento.
Por su carácter incremental es posible y deseable que los grupos de aprendizaje que utilicen estas capsulas
las enriquezcan y cree nuevas para su uso interno o para compartir.
Comunicate conmigo para enriquecer las cápsulas o para recibir notificaciones webinars y actualizaciones.
jgabardini | ​juan.gabardini@kleer.la​ | ​http://softwareagil.blogspot.com
Próximas Cápsulas
● Componentes del costo de la prueba (Mantenibilidad)
Influye en la decisión de que pruebas hacer y cuando (desarrollo, exploración, regresión)
● Nivel de Abstracción (Mantenibilidad)
Record & Play, Data-driven, Keyword-driven. Afecta a la estructura del equipo, las herramientas
usadas y el costo de las pruebas
● Pirámide de la prueba (Eficiencia y Eficacia)
Dónde invertir más en automatización
● Ambientes (Eficiencia y Eficacia)
Alternativas con los objetivos y características de cada uno.
● Automatización según el objetivo y el momento (Eficiencia y Eficacia - )
Confirmaciones (acuerdo previo al desarrollo), exploratorias (descrubrir comportamientos no
conocidos), regresión (que no hayan aparecido cambios).
Cápsulas de Testing v0.2 5 / 17

6. Modelo del Oráculo
¿​De qué depende​ el comportamiento del SUT?
¿Cómo determino el ​comportamiento esperado​ del SUT?
¿Cómo ​valido que el resultado​ obtenido es el esperado?
SUT: ​System under Test​ (sistema bajo prueba).
¿Cómo lo hago ahora?
Cuando diseñamos la pruebas, tomamos algunas entradas (​Input​),
identificamos el resultado esperado y definimos como compararemos los
resultados reales (​Output​) con los resultados esperados (​Expected​).
Toma una prueba que estés realizando en este momento o que realizaste
hace poco, piensa y anota:
● ¿Cuáles son las entradas al SUT que son relevantes para tu prueba?
¿Cuáles no son relevantes?
● ¿Cómo/quién definió los resultados esperados?
● ¿Cómo se compara los resultados obtenidos con los esperados?
¿Cómo se evalua si encontramos una falla o no?
Oráculos (Oracles)
Los Oráculos son mecanismos que nos permiten definir resultados esperada de una prueba.
Identificar, elegir, construir, aplicar los oráculos son actividades importantes en el diseño de la prueba.
Ejemplo de Oráculos:
● Experto: una persona que conoce el negocio. A veces el usuario, a veces un tester.
● Modelo: se dispone de una fórmula matemática o modelo, que puede implementarse en una
manera sencilla en una herramienta de prototipado rápido (Excel, MathLab).
● Sistema de referencia: queremos duplicar el comportamiento que ya existe, por ejemplo en un
sistema de la competencia o en la versión anterior de este mismo sistema.
● Invariantes: el resultado es fácilmente previsible porque es siempre el mismo.
Al analizar la prueba con esta óptica, es necesario también definir cuales son las entradas (​Input​) y la forma
de comparar (​Comparator​ & ​Evaluator​).
Entradas (Input)
Las entradas pueden o no afectar al comportamiento de la funcionalidad que queremos probar. Podemos
agrupar los valores según que tan interesante sea probarlos (clases de equivalencias, casos límites).
Tipos de entradas:
● Parámetros o datos de la funcionalidad probada
● Acciones: eventos o secuencia de eventos que quieren probarse.
● Contexto: software de base, hardware, idioma, fecha de sistema
● Estado del SUT: entidades en base de dato o memoria, configuración, historia
● Otros sistemas conectados
Cápsulas de Testing v0.2 6 / 17

7. ● Buenas Prácticas, OWASP
Resultados esperados (Expected)
Los resultados esperados pueden ser un comportamiento, reporte, modificacación del estado, interacción
con otros sistemas. En general, un cambio agrupable de la misma manera que los tipos de entrada.
Comparación
Usaremos como ejemplo:
Planificador financiero, toma un monto de préstamo y un monto mensual máximo y calcula la
cantidad de cuotas que de tal manera que nunca se supere el monto mensual. El banco tiene
intereses distintos según la cantidad de cuotas, seguro de vida según la deuda, costos
administrativos y sistema francés (las cuotas son siempre del mismo monto).
Comparar el resultado obtenido y el esperado consiste en:
● Definir cuales son las variaciones significativas entre ambos resultados. Puede ser ocurrencia de
eventos, tipos de datos resultantes, valores, transformación de los valores (por ejemplo funciones
estadísticas como promedio de valores).
En el ejemplo, nos interesa el número de cuotas y el monto máximo de las cuota; no nos interesa el
consumo de memoria o procesador. ¿Hay otros?
● Decidir como se realizarán las comparaciones. Pueden ser por igualdad, rangos, aproximaciones,
pertenencia a un conjunto de valores.
En el ejemplo, en dolares o pesos argentinos, el monto de las cuotas se compara redondeado a dos
decimales, mientras que en guaraníes o pesos chilenos redondeado a entero. ¿Puede haber
resultados no numéricos?
● Decidir cuando es aceptable el resultado (OK) o cuando es una Falla (Fail). El criterio depende de la
comparación, por ejemplo: el caso de igualdad es trivial; en el caso de rangos, abiertos o cerrados.
Lo resultados esperados pueden ser constantes o valores derivados, por ejemplo el número de
comprobante debe ser uno más que el último existente.
En el ejemplo, para ciertos valores de entrada esperamos valor de la cuota de $100.00 y 5 cuotas
esperamos que el resultado se igual a esos dos valores. ¿Puede haber ambigüedad en la
comparación en este caso?
Cápsulas de Testing v0.2 7 / 17

8.
Actividades
Aplica el modelo, solo o de a pares.
1. Analiza lo que hiciste en ​¿Cómo lo hago ahora?​, con este modelo. ¿Cuáles son las entradas, tipo de
oráculo y comparación?
2. Oráculo:
a. ¿Recuerdas casos reales que correspondan a cada tipo descripto?
b. ¿Algún caso que no corresponda a ninguno de los tipos / ejemplos comentados?
3. Entradas:
a. ¿Recuerdas casos reales que correspondan a cada tipo?
b. ¿Algún caso que no corresponda a ninguno de los tipos / ejemplos comentados?
4. Comparador:
a. ¿Recuerdas casos reales que correspondan a cada tipo?
b. ¿Algún caso que no corresponda a ninguno de los tipos / ejemplos comentados?
5. Toma un caso de tu día a día y busca una variantes en el tipo de Oráculo / Entrada los elementos
de modelo ¿Cuales son las ventajas y desventajas?
6. Fuzzing​: Investigá esta forma de diseñar y ejecutar casos de prueba y analizalo a partir de el
modelo del oráculo.
7. Chaos Monkey​: Investigá esta forma de diseñar y ejecutar casos de prueba y analizalo a partir de el
modelo del oráculo.
Conclusiones
1. ¿Cuales son los tipos de Oráculo / Entrada / Comparador descriptos?
2. ¿Cuáles son los tipos de Oráculo / Entrada / Comparador que más utilizás?
3. ¿Cuáles serían un par de ideas que te gustaría probar en tus próximas pruebas?
Referencias
● http://www.testingeducation.org/k04/OracleExamples.htm​ (tomado de Internet 30-ene-2017). En
esta referencia se usa una terminología ligeramente distinta. Oracle es el todo, e incluye generator,
comparator y evaluator.
● Relacionado con Pruebas Diagnósticas, Arquitectura Prueba.
Cápsulas de Testing v0.2 8 / 17

9. Preparacion Datos
¿​Cómo generar​ los datos de prueba?
¿Cómo lograr que los datos estén ​disponibles en el momento de la prueba​?
¿Cómo lo hago ahora?
Para ejecutar las pruebas automáticas, necesitamos que la aplicación o SUT (System Under Test) esté en
un estado conocido. Ese estado incluye los datos necesarios para la prueba.
Toma una prueba que estés realizando en este momento o que realizaste hace poco, piensa y anota:
● ¿Cómo obtuviste o generaste los datos de prueba?
● ¿Cómo lograste que esos casos de prueba estén cargados o disponibles para el SUT?
Generación de datos
Por Diseño​: Se inventan datos que ejecitan la funcionalidad a desarrollar. Los ejemplos pueden estar
basados en la experiencia en el negocio o en las hipótesis de uso futuro. Por ejemplo, generar datos que
corresponden a situaciones límites y de error, hayan ocurrido o no.
Datos Reales:​ Tomar un conjunto de datos de la aplicación actual o del problema a resolver. Por ejemplo,
tomar los concepros facturados en el último mes, o los clientes y movimientos de una sucursal durante el
año pasado.
Simulados​: Utilizar un algoritmo para generar datos. Por ejemplo, todas las combinaciones posibles de los
variables de entrada, o valores alearorios.
Object Mother​: Cada entidad de la aplicacion tiene un mecanismo para generar objetos de prueba.
Normalmente con datos default y las entidades adicionales las genera recursivamente. Por ejemplo, una
prueba que necesita un cliente, la prueba le pide a la entidad Cliente una instancia de prueba. Cliente genera
Cápsulas de Testing v0.2 9 / 17

10. un cliente que tiene un nombre y apellido default (Juan Perez). Para completar el país de nacimiento,
Cliente le pide a la entidad Pais una instancia de prueba.
Estado conocido
Cargar cada vez​: Cargar los datos para cada prueba. Esto puede hacerse a diferentes niveles: desde el
repositorio de los datos (base de datos, archivos), desde una capa de servicios o componentes, a traves de
la funcionalidad disponible para el usuario final. Puede cargarse a partir de un estado inicial vacío, o como
incremento. Puede ser necesario modificar datos (fechas, números de referencias cruzadas).
No cambiar​: Se llega al estado conocido y se lo proteje. Por ejemplo backup y restore de bases de datos, se
utilizan transacciones de base de datos, se realizan operaciones que no modifiquen datos o se realizan
operaciones que revierten la operación realizada en la prueba.
Existentes​: Asumiendo que tenemos un volumen alto y variado de datos, realizamos una búsqueda que nos
traiga un dato con las características que necesitamos.
Mock (o dobles)​: Reemplazamos un componente del sistema, que no nos interesa probar, por un
mecanismo que devuelva datos conocidos. Pueden ser siempre los mismos datos o puede ser más
inteligente.
Actividades
Analiza el siguiente ejemplo y proponer la estrategia para los datos de prueba:
Tenemos una aplicación monolítica que resuelve una parte central del negocio de nuestra organización.
Siguiendo las buenas prácticas actuales, se busca migrar hacia una arquitectura de microservicios. La
migración será incremental, y en cada micro servicio se va a realizar en dos fases: duplicar funcionalidad
mínima de la aplicación actual, y luego agregar funcionalidad nueva, valiosa para el negocio.
La aplicación actual tiene algunas pruebas automatizadas a través de la UI.
Queremos que puedan trabajar en paralelo los equipos que modifican el sistema monolítico remanente y los
que desarrollan cada nuevo micro servicio.
¿Qué alternativas tenemos para generar los datos de prueba?
¿Cuáles son los pros y contras de cada una de las alternativas?
Cápsulas de Testing v0.2 10 / 17

11. Pruebas Diagnósticas
¿​Cómo diseño​ la prueba ​para aprender​ lo que quiero aprender?
¿​Cuánta confianza tengo​ en los resultados obtenidos?
¿Cómo lo hago ahora?
Cuando revisas los resultados de la ejecución de tus pruebas automáticas, ¿qué confianza tenés en que los
rojos sean errores de la aplicación o SUT (System Under Test)? ¿Y que los verdes sean que el SUT funciona
bien?
Las pruebas diagnósticas
Queremos averiguar algo. Por ejemplo, si una mujer está embarazada. Para ello, se identifica una
característica que sea relativamente fácil de medir, y que esté relacionada con lo que queremos averiguar.
En el ejemplo, la presencia de una hormona particular. Y aún podemos discutir si es posible una forma
manual (extracción de sangre y análisis de laboratorio) o un automática (análisis de orina realizado por la
misma persona).
En cuanto a resultados de la prueba puden ser:
● Positivo (P): encontramos lo que buscábamos. En el ejemplo, un nivel de hormona mayor a cierto
nivel.
● Negativos (N): no encontramos lo que buscabamos.
Aún resta evaluar si la prueba realmente indica un embarazo o es un resultado falso, producido por ejemplo
por contaminación de la muestra (sangre u orina), cambios del nivel de la hormona por otras causas
oprueba realizada incorrectamente.
En cuanto a la calidad del resultado la prueba puede ser:
● Verdadero (V): el resultado refleja la condición actualmente existente
● Falso (F): el resultado no corresponde con la condición existente.
Cápsulas de Testing v0.2 11 / 17

12. Confiabilidad
Cuando tomamos decisiones basándonos en los resultados de la prueba, nos interesa saber cuanta
confianza podemos depositar en el resultado.
Para medir la confianza, usamo la probabilidad. Decimos que tenemos certeza absoluta en un Positivo,
cuando todas las veces que la prueba da Positivo, ese resultado es verdadero. En ese caso la probabilidad
de Positivo Verdadero es del 100% y la del Positivo Falso sería 0%. La suma de las probabilidades de
Verdadero y Falso simpre deben dar 100%
Podemos mejorar la confiabilidad de varias maneras:
● Haciendo la prueba más robusta. En el ejemplo de contaminación de la muestra, podemos
investigar las causas de contaminación y ajustar los procedimientos para evitarlos.
● Ajustando los parámetros. Por ejemplo subiendo el nivel de hormana que considermos indicador de
embarazo. Este ajuste tiene impacto en mejorar la confiabilidad del Positivo (aumenta la
probabilidad de Positivo Verdadero), pero disminuye la del Negativo (aumenta la probabilidad del
Negativo Verdadero).
● Realizando varias pruebas. Se puede repetir la misma prueba o realizar pruebas distintas. En el
ejemplo, podemos hacer pruebas de orina, de sangre o ecografías para aumentar la confiabilidad.
Actividades
1. Probamos un sitio de comercio electrónico del tipo B2C (Amazon). Tenemos algunas pruebas
hechas para validar que el sitio esté funcionando bien:
a. Realizar un GET (wget o curl) a la home y verificar que el código de respuesta sea 200
(OK).
b. Recorrer la aplicación como usuario no logeado, como si fuera un crawler de un buscador.
Verificar que sólo retorne códigos en el rango del 2xx o 3xx.
Para cada prueba, evaluá la confiabilidad de los resultados Positivos y Negativos.
2. Si tuvieras que priorizar confiabilidad entre resultados Positivos y Negativos, ¿Cuál priorizarias?
Considerá prueba de smoke test, unitarias, de integración, de sistema, de aceptación.
3. Toma un caso actual o pasado de automatización en el que hayas participado. ¿Cómo estimas que
sería la confiabilidad de los resultados? ¿Si quisieras mejorarlo, que harías?
Cápsulas de Testing v0.2 12 / 17

13. Arquitectura de prueba automática
¿​Qué componentes​ tiene tu prueba automatizada?
¿​Cómo​ es mi ​equipo​? ¿​Qué​ ​quiero lograr​ con la prueba?
¿Cómo lo hago ahora?
La automatización de la prueba de software es un tipo particular de sistema de software, a veces llamado
framework de prueba o stack de prueba.
Como cualquier sistema de software, tiene una arquitectura que tiene atributos de calidad. En este caso
suele ser relevantes: usabilidad, extensibilidad, mantenibilidad, performance, confiabilidad.
Toma una prueba automatizada que estés realizando en este momento o que realizaste hace poco, piensa y
anota:
● ¿Cómo se mide con respecto a los atributos de calidad relevantes?
● ¿Quienes son los usuarios de ese sistema (del stack de prueba)?
Arquitectura del Sistema de pruebas automáticas
SUT: System Under Test o sistema siendo probado
Para qué explicitar una arquitectura
Algunas familias de herramientas de prueba (como Mercury, Rational, Silk y TestComplete) están pensadas
para resolver toda la problemática de la prueba y tienen la arquitectura definida por el fabricante.
En otros casos (como Selenium, FitNesse, Cucumber y RobotFramework) las herramientas resuelven sólo
algunos de los aspectos de la prueba. Suelen usarse combinadas con otras herramientas.
Cápsulas de Testing v0.2 13 / 17

14. Definir una arquitectura nos permite tener un lenguaje común para poder discutir stacks alternativos
cuando se está diseñando una solución de prueba.
Los usuarios
Negocio (BIZ)​: Tienen conocimiento profundo del dominio, son quienes definen los criterios de aceptación
y están interesados en revisar si los ejemplos (TC) reflejan las reglas de negocio.
Tester​: Suelen ser responsables de escribir y mantener los TC, extendiendo las definiciones de Negocio con
los ejemplos (TC) de caminos no felices, condiciones de borde, etc. Se ocupan de visibilizar los resultados
de las pruebas
Técnicos (Tech)​: Colaboran para que los ejemplos se comuniquen y ejecuten contra la versión correcta del
SUT. Programan, instalan, operan. Requieren información para debugging y operación.
Automation​: Otros sistemas relacionados, como los correspondientes a Integración Continua o Entrega
continua.
Los componentes
Por cada componente, describo brevemente el alcance del mismo y algunos ejemplos de su instanciación
en herramientas existentes.
Editor​: Cómo creo y edito casos de prueba. En ocasiones una herramienta ad hoc, en otros casos una
herramienta genérica.
Selenium: Selenium IDE, permite grabar acciones desde la aplicación o editar los TC.
WebDriver: editor/IDE del lenguaje de programación usado.
RobotFramework: RIDE, permite editar TC en forma 'inteligente', o editores de HTML.
FIT: Word, Excel y editores de HTML.
FitNesse: wiki.
Cucumber: cualquier editor de texto.
Test Case (TC)​: Repositorio de mis casos de prueba, con o sin estructura y con un lenguaje con el que
escribo mis casos de prueba. Puede incorporar la posibilidad de definir términos nuevos que abstraigan
complejidad.
Selenium IDE: Los casos de prueba se escriben con Selenese, básicamente un HTML con una tabla
de tres columnas. La estructura de casos está dada por las suite, que es una tabla HTML con los
casos.
WebDriver: No tiene forma nativa de representar los casos de prueba o la estructura. Debe usarse
un Runner de otra herramienta y sintaxis de lenguaje de programación usado. Extensión usando el
lenguaje de programación.
RobotFramework: HTML (tablas), TSV, reST. Permiten extender el DSL de prueba con user
keywords.
FitNesse: wiki markup languaje (tablas). Permiten extender el DSL de prueba con Scenario.
Cucumber: Gherkin y permiten extender el DSL de prueba con Scenario Outlines.
Interprete​: Interprete del lenguaje de TC, incluyendo mecanismos para definir o extender un DSL.
Selenium: plugin de Firefox, y se extiende con plugins adicionales.
Cápsulas de Testing v0.2 14 / 17

15. WebDriver: la parte correspondiente a WebDriver es interpretada o compilada por el lenguaje en el
que se escribieron los TC (Java, Ruby, Python, etc), y resuelto con la API provista por la biblioteca
de Selenium.
RobotFramework: interprete del lenguaje propio (test data syntax), se extiende con library
keywords.
FitNesse: interprete de HTML (modo compatibilidad con FIT) a través de una conversión interna
entre wiki text y HTML, o directamente wiki text en el caso de SLIM. Extensión usando Fixture.
Cucumber: interprete de Gherkin más los steps creados.
Adaptador​: Cero, uno o más capas de adaptación entre los TC interpretados y el sistema bajo prueba
(System Under Test o SUT). La forma de conexión depende del tipo de prueba que se quiere hacer, por
ejemplo conexión con: interfaz usuario, API REST, u objetos de la aplicación.
SUT Web: un ejemplo sería WebDriver usado para automatizar la aplicación a través de la interfaz
web, más PhantonJs para simular un browser.
SUT Desktop: un ejempo es Abbot para pruebas de Java Swing o White para pruebas GUI sobre
Windows usando UIAutomation.
Comparador​: El mecanismo de comparación entre resultados esperados y los resultados reales. El
comparador puede tener conocimiento semántico y sintáctico sobre el resultado (Output) del SUT, para
poder hacer comparaciones más significativas y concisas. En este sentido puede estar ligado a los
adaptadores. En otras casos está implementado en el Interprete. Y también puede ser extendido.
Cucumber: la base de los comparadores corresponde a las expectations de RSpec, pero se
enriquecer, por ejemplo con los Capybara Matchers.
Fitnesse: una de las diferencias entre el Interprete FIT y SLIM es los comparadores adicionales
(rangos, aproximados, mayor o menor). Adicionalmente, en SLIM se pueden enriquecer con Custom
Comparators.
Runner​: Permite ejecutar los TC. Pueden ejecutar TC secuencialmente o en paralelo; un TC, todos los TC o
algún subconjunto (los que tienen cierta marca o tag, los que han fallado, etc). Adicionalmente, algunos
permiten indicar dependencias entre TC y generar dinámicamente TC tomando datos de una base de datos
o planilla.
Los Runner también tiene mecanismos para indicar cuando un TC ejecutado ha sido exitoso o no y
mecanismos de preparación y limpieza de las pruebas. Invocan a la generación de reportes.
Cucumber: se invoca por linea de comando y puede usarse el runner de JUnit (con cucumber-JVM)
FitNesse: se puede ejecutar las pruebas desde la wiki, por linea de comandos, por servicios REST y
puede usarse el runner de JUnit.
TestNG: una librería Java (alternativa a JUnit), permite indicar dependencias entre TC.
Reporter​: Crea los reportes de seguimiento de los resultados de la prueba. Distintos usuarios del sistema
de pruebas requieren distintos reportes: resumen al momento, evolución temporal, detalle de casos
ejecutados, etc. Es este área el formato XML de JUnit es el standard de facto. Aunque varias herramientas
tienen alternativas: sólo texto o HMTL. Además, algunas herramientas consolidan infomación para brindar
visibilidad, como Jenkins o SonarQube.
Caso Cacique Test - MercadoLibre
Cápsulas de Testing v0.2 15 / 17

16. Sitio de comercion electrónico, con desarrollo web monolítico (Java). El Equipos de prueba y programación
están separados. Los testers tienen poco conocimientos técnico, los programadores no toman la prueba
como una responsabilidad compartida.
Objetivo de la prueba: reducir el tiempo de ejecución de las pruebas de regresión.
Criterio: Aprovechar el conocimiento funcional de los testers sin esperar a que desarrollen sus habilidades
técnicas.
Solución: Desarrollar una solución basada en Selenium IDE (que permite grabar los pasos de una prueba
web en un archivo HTML). La solucion debe correr desatendida y permitir parametrizar los TC para tomar
varios valores desde tablas. Para ello, se contratan programadores de Ruby, que implementan una
herramienta (Cacique Test) que resuelva la infraestructura de la prueba en paralelo (basado en Selenium
Grid), permita a lo testers copiar y pegar desde Selenium IDE los script Ruby y modificarlos para recibir los
datos parametrizados.
En este caso, los componentes afectados fueron:
● Editor: Se usa Selenium IDE inicialmente, pero se agrega la posibilidad de reemplazar algunos
datos por parámetros y además luego se pueden editar directamente en la herramienta.
● Test Case: Se almacenan en una base de datos para el script y se agregan referencias a las tablas
de datos, que también están en base de datos.
● Intérprete: Ruby más la lógica para tomar los parámetros desde tablas.
● Runner: Se basa en Selenium Grid, pero tienen una capa por arriba, para tomar los TC desde la base
de datos.
Conclusiones
Los equipos de desarrollo de software pueden diseñar su sistema de pruebas automáticas en forma
iterativa e incremental, de igual manera a como se desarrolla el producto. Se empieza por la forma más
sencilla y se mejora cuando es necesario.
¿Por dónde empezarías? ¿Cómo cambiarías el que tenés ahora?
Actividades
1. Analiza este caso:
Desarrollo web/mobile front-end / back end. Equipos de Mobile, Web y Backend, cada uno con
testers y programadores. Como equipo, se toma responsabilidad de calidad.
Objetivo: minimizar problemas de compatibilidad de APIs en el equipo de Backend.
¿Cuáles son los roles y que necesidades tienen? ¿Qué arquitectura utilizaría?
2. Revisar la herramienta BDD Assistant (​http://vfarcic.github.io/sbe_bdd​), ¿A qué compontente de la
arquitectura corresponde? ¿Qué objetivo busca cubrir?
Cápsulas de Testing v0.2 16 / 17

17.
Cápsulas de Testing v0.2 17 / 17