Un framework (marco de trabajo) dará pautas, estructura e incluso buenas prácticas para probar un sistema, lo que provocará seguir un estándar para facilitar el trabajo en equipo.
Algunos de los frameworks más famosos o más usados son:
Capture/Playback
Linear Scripting
Structured Scripting
Module Based
Data-driven
Keyword-driven
Hybrid
Behavior Driven Development (BDD)
Frameworks de pruebas más usados
A continuación se explicarán los frameworks de pruebas más usados:
Capture/Playback
El framework Capture/Playback consiste en grabar con una herramienta lo que el usuario ejecuta y reproducirlo como casos de prueba(scripts) grabados.
Las ventajas de capture/playback son:
El enfoque captura/reproducción se puede utilizar para el System Under Test (sistema bajo prueba, SUT) en el nivel de una interfaz de usuario y/o API.
Es fácil de configurar y usar para alguien sin experiencia previa.
Las desventajas de capture/playback son:
Es difícil de mantener, porque es necesario grabar la aplicación cada vez que esta cambie.
La implementación de los casos de prueba (scripts) solo puede comenzar hasta que el sistema esté disponible.
Linear Scripting
El framework Linear Scripting se asemeja a Capture/Playback, pero se diferencia en que el linear scripting permite observar y manipular el código grabado, mientras que en el Caputure/playback es inaccesible. Algunos autores los agrupan en el mismo tipo.
Las ventajas de linear scripting son:
Se puede utilizar parar probar el sistema a nivel de interfaz de usuario y/o API.
Fácil de configurar.
Las desvetajas de linear scripting son:
El costo de mantenimiento es lineal, no se pueden reutilizar los scripts, por lo que en productos grandes no es recomendable.
La cantidad de esfuerzo es lineal, para cada caso de prueba necesitas un archivo de código.
Es difícil de mantener, porque es necesario grabar la aplicación cada vez que cambie.
Structured Scripting
El framework Structured Scripting permite reutilizar el código de los casos de prueba.
Las ventajas de structured scripting son:
Existe una reducción del mantenimiento, por la reutilización de código.
Reutilización de secuencias de comandos.
Reducción de costos de construcción y manteniento.
Las desventajas de structured scripting son:
Requiere un mayor esfuerzo inicial, tratar de dividir los scripts para que sean reutilizables.
El equipo o encargado debe poseer habilidades de programación.
Se necesita una buena administración.
Module Based
El framework Module Based se basa en módulos relacionados con los principios de la programación orientada a objetos (POO). Los módulos están separados por una capa de abstracción, de tal forma que los cambios puedan ser realizados en las secciones de la aplicación.
Las ventajas del Module Based son:
Escalabilidad, podrás heredar atributos o propiedades en el código siguiendo la programación orientada a objetos.
Flexibilidad y facilidad de mantenimiento.
Modularización.
Las desventajas de Module Based son:
No se tiene flexibilidad en los datos, la información debe estar escrita en el código.
Data-Driven
El framework Data-Driven se basa en una estructura semejante a la de Module Based, la diferencia es que maneja entradas de datos al ser ingresados por el usuario, sin la necesidad de tener la información en el código.
Por ejemplo, si se requiere probar un inicio de sesión, no es necesario ir al código y cambiar las credenciales manualmente, sino extraer la información de un archivo de Excel, bases de datos, API, entre otros.
Las ventajas de Data driven son:
Comparado con los frameworks anteriores, el costo se reduce considerablemente, ya que la información es más fácil de manejar.
Aumenta la cobertura, porque será más fácil cubrir diferentes escenarios y probar la aplicación con diferentes valores.
Flexibilidad de ejecución.
Las desventajas de Data driven son:
Esfuerzo adicional para establecer, configurar y mantener las fuentes de datos.
Dominio de algún lenguaje de programación.
Keyword-Driven
El framework Keyword-Driven consiste en realizar acciones en el código a través de una palabra reservada(keyword). Lo que hará será activar una determinada acción según el procedimiento (step number), por ejemplo en la siguiente imagen observarás que primero se ejecutará un inicio de sesión (login), después un clic en un botón (clickButton) y así sucesivamente.
Las ventajas de Keyword-driven son:
Flexibilidad en la creación de pruebas, porque puedes utilizar cualquier combinación de pasos.
Reutilización de código y, por lo tanto, el costo de mantenimiento es menor.
No se requiere conocimiento de las secuencias de comando, solo se necesita conocer qué hace cada palabra clave (keyword).
Las desventajas de Keyword-driven son:
Incremento de dificultad a medida que se introducen nuevas palabras clave.
Complejidad de aprendizaje.
Hybrid (Data-driven + Keyword-driven)
El framework Hybrid consiste en una combinación de Data-driven y Keyword-driven, en el cual se tiene la información que desea utilizar en una acción determinada por la palabra clave (keyword) en un determinado paso (step number).
Behavior Driven Development
El framework Behavior Driven Development (BDD) es un marco de desarrollo impulsado por el desarrollo que contiene un lenguaje sencillo de leer para cualquiera. Normalmente, se utiliza un lenguaje natural Gherkin que consta de tres partes:
Given: nos da las precondiciones de la prueba.
When: nos da el detonante de la acción.
Then: permite validar con un criterio de aceptación.
Las ventajas de BDD son:
Existe una mayor compatibilidad entre historias de usuario y casos de prueba (test cases).
Claridad en los casos de prueba.
Hay una reutilización de código, porque cada sentencia tiene un componente reutilizable.
Es Data-Driven, porque tiene una funcionalidad llamada escenarios outline que permiten guardar información y utilizarla.
Las desventajas de BDD son:
Mayor dedicación de tiempo.
Mayor tiempo de planificación en la estructura del código y sus sentencias.
Conocimiento de Gherkin o similar.
Contribución creada con los aportes de: Andrés Guano.
Aportes 64
Preguntas 5
Ordenar por:
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
Siento que clase estuvo algo larga y creo que entendí lo que hacía cada framework pero al ser algo tan abstracto siento que no me alcanzo a imaginar bien un caso de uso donde lo usaría o cosas así.
Por ejemplo creo que entendí lo de Data-Driven y Keyword-Driven pero no un ejemplo claro donde se utilizó o se utilizaría 🤔 se explica bien el concepto, ventajas y desventajas pero no mucho su implementación (en mi opinión)
El framework que usamos en la empresa donde trabajo es el BDD, usamos las tecnologías: Cucumber, Gherkin, Java y selenium/appium (web/mobile), adicional en algunos proyectos tambien usamos serenity con cucumber.
El uso de herramientas por lo general depende del tipo de proyecto y del cliente, algunos clientes prefieren usar TDD.
Adicional me gustaria nombrar algunos de los patrones de diseño usados en los frameworks para automatización de tests:
TIPOS DE FRAMEWORKS DE AUTOMATIZACIÓN
.
En una traducción un framework es un marco de trabajo, es decir, ofrece pautas, estructura, buenas practicas de como probar un sistema.
.
El mayor beneficio es estandarizar un proceso de prueba. lo cual proporciona una estructura viable para facilitar el trabajo.
. Frameworks mas populares
. CAPTURE/PLAYBACK
.
Permite capturar y volver a reproducir. Este tipo de frameworks hacen uso de herramientas que permiten grabar una acción o la pantalla para después reproducir ese script que se halla hecho.
.
Pros
El enfoque de captura/reproducción se puede utilizar para el SUT (System Under Test) en el nivel de GUI y/o API. inicialmente, es fácil de configurar y usar.
.
Contras
Es didicil de mantener debido a que una aplicación cambia constantemente lo cual implica tener que volver a grabar la prueba de principio a fin cada vez que algo cambie y la implementación de los scripts solo pueden comenzar cuando el sistema este disponible.
.
LINEAR SCRIPTING
.
Es muy parecido al capture/playback. La diferencia es que Linear Scripting produce un código el cual es accesible.
.
Pros
Se pude utilizar para probar el sistema a nivel GUI y/o API y es facil de configurar.
.
Contras
Requiere un gran esfuerzo en mantenerse debido a que es lineal y difícil y costoso de mantener.
. STRUCTURED SCRIPTING
.
A diferencia de Linear Scripting permite reutilizar los scripts y los diferentes test.
.
Pros
Reducción del mantenimiento con la reutilización de secuencias de comandos lo que reduce los costos de construcción y mantenimiento.
.
Contras
Requiere un mayor esfuerzo inicial con habilidades de programación y administración.
. MODULE BASED
.
Es un framework basado en modulos se basa en los conceptos de la programción orientada a objetos a difrencia del Structured Scripting los modelos están separados por una capa de abstración de tal forma que los cambios pueden ser realizados en las secciones de la aplicación y no producen efectos en este modulo.
.
Pros
modularizacion ya que permite mas escalabilidad y flexibilidad de mantenerlo. ya que cada mantenimiento es replicable en todos los módulos que lo usen.
.
Contras
Sin flexibilidad de datos.
. DATA-DRIVEN
.
Este framework se basa en una estructura parecida a la de Structure Scripting y Model Based. La diferencia mas significativa es que maneja entradas de prueba, donde se extraen de los scripts para utilizarlos en archivos separados.
.
Pros
Bajo costo de mantenimiento ya que los archivos se leen de una base de datos, aumenta la cobertura para cubrir diferentes escenarios y hay flexibilidad de ejecución.
.
Contras
Recibe un esfuerzo adicional en las fuentes de datos y el dominio de un lenguaje de programación.
. KEYWORK-DRIVEN
.
Es un framework de pruebas basado en palabras claves. Donde un keyword es una palabra reservada que indica una acción en el código.
.
Pros
Tiene una mayor flexibilidad ce creación de pruebas. porque el QA tiene el control manual de poder crear pruebas, delimitar el orden y configurar datos ademas no requiere un conocimiento de las secuencias de un comando.
.
Contras
Tiene mayor complejidad de aprendizaje con lo que se genera un incremento en la dificultada a medida que se introducen palabras clave.
. HYBRID
.
Es una combinación entre los frameworks Keyboard-Driven y Data-Driven. Permite tener los pros y contras de ambos.
. BEHAVIOR DRIVEN DEVELOPMENT
.
Este framework es impulsado por comportamiento. Normalmente consta de 3 partes, usa un lenguaje de 3 palabras reservadas.
Given.
When.
Then.
.
Pros
Cuenta con mayor compatibilidad entre historias de usuarios y test cases por lo que tiene claridad en los casos de prueba donde el encargado va poder leerlos de una manera muy sencilla y tiene un feature de reutilización de código y es Data-Driven.
.
Contras
Requiere una mayor inversión de tiempo donde las personas encargadas de hacer las pruebas al sistema deben aprender a usar las herramientas y hacer una planificación la estructuración de todos los archivos, carpetas, etc.
Me super encanto el BDD, en serio que sería muy útil para implementar en cualquier compañía.
Rescato también el Hybrid, pues para ciertos casos es muy útil.
Con esto quiero decir, que cuando eres un analista QA, QC, lo que debes es analizar muy bien con estrategias de pruebas y un gran plan de pruebas, que se va a implementar durante todo el proyecto, de modo tal que los costos sean mínimos y finalmente tengamos una satisfacción del cliente final.
### 1. **Capture/Playback**
**Descripción**: Este enfoque implica grabar acciones del usuario en una interfaz gráfica (GUI) y luego reproducir estas acciones para realizar pruebas.
**Casos de uso**: Se utiliza principalmente para pruebas de regresión para asegurar que cambios recientes no hayan roto funciones existentes.
**Herramientas**:
* TestComplete
### 2. **Linear Scripting**
**Descripción**: Similar al Capture/Playback, pero los scripts se escriben manualmente en lugar de ser grabados.
**Casos de uso**: Útil para escenarios de prueba sencillos y directos sin necesidad de reutilización de código.
**Herramientas**:
* Appium
* Katalon Studio
### 3. **Structured Scripting**
**Descripción**: Los scripts de prueba se organizan de manera más estructurada y modular, permitiendo la reutilización de código.
**Casos de uso**: Aplicaciones grandes donde mantener los scripts de pruebas es crítico y la reutilización puede ahorrar tiempo.
**Herramientas**:
* TestNG (para Java)
* NUnit (para .NET)
### 4. **Module Based**
**Descripción**: El sistema bajo prueba se divide en módulos independientes y cada módulo tiene su conjunto de scripts de prueba.
**Casos de uso**: Ideal para proyectos grandes y complejos donde se puede testear independientemente cada módulo.
**Herramientas**:
* Selenium WebDriver para crear suites de pruebas modulares
* QTP/UFT
### 5. **Data-driven**
**Descripción**: Los scripts de prueba se ejecutan múltiples veces utilizando diferentes conjuntos de datos desde una fuente externa.
**Casos de uso**: Pruebas de funcionalidad que requieren validar con diferentes conjuntos de datos, como formularios o puntos de entrada de usuario.
**Herramientas**:
* Apache POI (para leer datos de Excel en Java)
* Selenium WebDriver
* TestNG o JUnit para la gestión de tests
### 6. **Keyword-driven**
**Descripción**: Los scripts de prueba se basan en palabras clave que representan acciones a realizar en la aplicación.
**Casos de uso**: No técnico o para equipos con miembros que no sean programadores, permitiendo que ellos también puedan escribir casos de prueba.
**Herramientas**:
* Robot Framework
* Katalon Studio
### 7. **Hybrid**
**Descripción**: Combina elementos de varios enfoques, como Data-driven y Keyword-driven, para aprovechar los beneficios de cada uno.
**Casos de uso**: Proyectos que requieren flexibilidad en técnicas de prueba y donde se pueda aprovechar la reutilización de componentes.
**Herramientas**:
* Selenium WebDriver
* QTP/UFT
### 8. **Behavior Driven Development (BDD)**
**Descripción**: Las pruebas están diseñadas alrededor del comportamiento esperado del software, utilizando un lenguaje que es comprensible para los desarrolladores, testers y stakeholders.
**Casos de uso**: Equipos que practican Agile y que desean mejorar la comunicación entre desarrolladores, testers y clientes.
**Herramientas**:
* Cucumber
* SpecFlow
* Behave
El Framework que mas me gusto es BDD ya que se puede mantener una re utilización de las feature levantadas en el proyecto; además es transparente para área funcional.
No me quedo muy clara la clase, aunque después de analizar los diagramas de cada framework y relacionarlos con como funcionarían a nivel de programación, más o menos me puedo hacer una idea de como funcionan algunos de ellos, puedo estar equivocado, pero voy a compartir lo que entendí de cada uno:
**Linear Scripting**
![]()
Este lo entendí como un programa que no tiene implementado ninguna funcionalidad de test interna. Por ende, se crean scripts que interactúen con la página de manera similar a como lo haría un usuario para probar diferentes casos. Este podría ser útil cuando quieres hacer pruebas en un sistema al cual no tienes conocimientos ni acceso a su código.
**Structured Scripting**
Este sería en el caso de que el código como tal tenga implementadas funciones de prueba. Por ejemplo, un programa donde se tenga una función para calcular los días entre 2 fechas que, por una parte, se use para dar información al usuario final en un formato más amigable, pero que a su vez esté disponible para que los testers puedan ejecutarla directamente con 2 fechas arbitrarias y probar que la operación esté dando los resultados correctos. Así se pueden creas scripts que llamen directamente a estas funciones en vez de tener hacer todos los proceso que un usuario normal necesita realizar para que estas funciones se ejecuten.
**Module Based**
![]()
Este lo entiendo como, en vez de crear varios scripts para cada funcionalidad a testear, se crea un gran programa donde en vez de usar scripts para probar cada funcionalidad, se crean funciones destinadas específicamente a probar dichas funcionalidades con lo cual es más fácil reutilizar el código y adaptarlo a los cambios del programa.
**Data-Driven**
No sé si me esté equivocando, pero este framework lo veo complementario a los anteriores, en el sentido que su innovación es tener un repositorio de datos para realizar las pruebas, por ejemplo, una base de datos de usuarios de prueba con sus contraseñas para que los scripts puedan probar cada uno y ver los resultados sin necesidad de escribirlos manualmente.
**Keyword-Driven**
De manera similar al anterior, considero que se trata de añadir una capa por encima de los scripts, en este caso que ejecute funciones o scripts específicos dependiendo de la palabra clave que se escriba. Con lo cual, una vez escrito el código, para realizar las pruebas solo se necesita de alguien que escriba la serie de funciones que quiere probar en su orden especifico y el programa de testeo leerá estas palabras y ejecutara las funciones necesarias.
**Hybrid**
La diferencia entre este y el anterior es que aquí se pueden ejecutar funciones que necesiten parámetros simplemente añadiéndoles a la columna de “data” dentro del archivo.
**Behavior Driven Development**
Este sería similar al caso anterior, pero usando una sintaxis que nos da más control sobre las acciones que vamos a tomar con respecto a simplemente escribir las acciones en un formato de texto plano
Tipos de automatizacion
-Capture/Playback: Captura y reproduce el scrypt grabado
Pros: El enfoque SUT,GUI, API. Inicialmente es facil de usar
Contra: Dificil de mantener, la implementacion de los casos de prueba solo puede comenzar hasta que el sistema este disponible
-Linear Scripting: es igual al capture, pero da acceso al codigo para poner comentarios
Pros: El enfoque SUT,GUI, API, facil de implementar
Contras: Cantidad de esfuerzo, dificil de mantener, costo de mantenimiento es lineal
-Structured scripting: no es lineal, nos permite reutilizar los scrypt en diferentes test
Pros: reduccion de mantenimiento, reutilizacion de secuencia de comandos, costos de construccion y mantenimiento.
Contras: Esfuerza inicial, habilidades de programacion, administracion.
-Module based: basado en modulos, se basa en la Programacion orientada a objetos, trata de abstraer, la diferencia es que estan separados en una capa y los cambios se pueden realizar en la seccion de la aplicacion sin presentar efectos en el codigo.
Pros: Modularizacion, escalabilidad, Flexibilidad y facilidad de mantenimiento
Contras: sin flexibilidad en los datos
-Data Driven: puedo usar datos externos para usarlos en la prueba, sin tener que quemar los datos en el codigo
Pros: Costo, aumenta la cobertura, flexibilidad de ejecucion
Contras: Esfuerzo adicional en las fuentes de datos, dominio de algun lenguaje de programacion
-Keyword Driven: marco de pruebas basado en palabras claves, extencion de basado en datos, nos ayuda a identificar acciones en el codigo y verifica que se cumpla las funciones con datos de entrada
Pros: Flexibilidad en la creacion de pruebas, Reutilizacion de codigo, no se recquiere conocimiento de las secuencias de comando
Contras: Complejidad de aprendizaje, incremento de dificultad a medida que se introducen palabras clave.
-Hybrid: combina Keyword y el Data dentro de un scryp para realizar pruebas
-Behavior driven development: es un lenguaje tipo gherkin donde consta de 3 palabras reservadas given, when y then.
Pros: Mayor compatibilidad entre historias de usuario y test cases, claridad en los casos de prueba, reutilizacion de codigo, data driven
Contras: Inversion de tiempo, Tiermpo de planificacion, conocimiento de gherkin o similar
En lo personal uso BDD y Data-Driven, lo cual es un error de mi parte ya que si uso BDD puedo usar Data-Driven simultaneamente, algo para mejorar, en un no tan lejano futuro.
Creo que ayudaría mucho tener ejemplos de los tipos de Framework para asentar el concepto, con esta explicación no se conecta la teoría con lo que existe en el mercado para tomar una decisión de cual aprender: Selenium, Cypress?. En lo personal ha sido mi gran disyuntiva, cual o cuales son los que debería aprender.
Buena tarde, el framework que más me gustó es el Behavior Driven Development, tienes varias ventajas entre la reutilización de código y es más claro, y en sus desventajas es algo fácil de adecuar que son los conocimientos y la dedicación.
El Behavior Driven Development es uno de los mas completos ya que se puede reutilizar el código, hay palabras reservadas, es fácil de entender (Gherkin)
En lo personal considero que el Behavior Driven Development es uno de los mas completos ya que se puede reutilizar el código, hay palabras reservadas, es fácil de entender y ademas permite al tester aprender mas a cerca de la programacion.
El que más me llamo la atención es el Hybrid, aunque me hubiera gustado ejemplos mas gráficos para poder comprender mejor las diferencias entre cada una
No sé por qué, pero me viene a la mente cuando estábamos haciendo un app con el Profe DeGranda con la web Batabit, donde nos hizo que usáramos una herramienta de Google llamado LightHouse.
A pesar de ser una explicación rápida. Es una introducción adecuada frente a los tipos de framework de automatización. En el momento estamos trabajando pruebas automatizadas con BDD. Una vez entiendes el leguaje Gherkin y la construcción de los feature se hace mas sencillo el trabajar este framework, así como mantenerlo.
En mi caso la mejor opción es Behavior Driven Development -BDD porque es la mas completa y contiene aspectos de otros framework. Es verdad que requiere un mayor tiempo y adaptabilidad pero el esfuerzos e vera recompensado. Se generan beneficios tanto para la parte funcional, como para desarrollo y pruebas.
me gustó muchísimo BDD y las bondades que puede brindar este framework al usar gherkin que es muy similar al lenguaje natural y disponible en varios idiomas
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?