A framework will give guidelines, structure and even best practices for testing a system, which will cause to follow a standard to facilitate teamwork.
Some of the most famous or most used frameworks are:
Capture/Playback
Linear Scripting
Structured Scripting
Module Based
Data-driven
Keyword-driven
Hybrid
Behavior Driven Development (BDD)
Most used testingframeworks
The most commonly used testing frameworks will be explained below:
Capture/Playback
The Capture/Playback framework consists of recording with a tool what the user executes and playing it back as recorded test cases(scripts).
The advantages of capture/playback are:
The capture/playback approach can be used for System Under Test (SUT) at the level of a user interface and/or API.
It is easy to set up and use for someone with no prior experience.
The disadvantages of capture/playback are:
It is difficult to maintain, because it is necessary to record the application every time it changes.
The implementation of test cases (scripts) can only start until the system is available.
Linear Scripting
The Linear Scripting framework is similar to Capture/Playback, but differs in that linear scripting allows the recorded code to be observed and manipulated, while Capture/Playback is inaccessible. Some authors group them in the same type.
The advantages of linear scripting are:
It can be used to test the system at the user interface and/or API level.
Easy to configure.
The disadvantages of linear scripting are:
Maintenance cost is linear, scripts cannot be reused, so in large products it is not recommended.
The amount of effort is linear, for each test case you need a code file.
It is difficult to maintain, because it is necessary to save the application every time it changes.
Structured Scripting
Structured Scripting framework allows to reuse the code of test cases.
The advantages of structured scripting are:
There is a reduction in maintenance, because of code reuse.
Reuse of scripts.
Reduction of construction and maintenance costs.
The disadvantages of structured scripting are:
It requires a greater initial effort, trying to divide the scripts so that they are reusable.
The team or manager must have programming skills.
Good administration is needed.
Module Based
The Module Based framework is based on modules related to Object Oriented Programming (OOP) principles. The modules are separated by an abstraction layer, so that changes can be made in the application sections.
The advantages of Module Based are:
Scalability, you will be able to inherit attributes or properties in the code following object oriented programming.
Flexibility and ease of maintenance.
Modularization.
The disadvantages of Module Based are:
No flexibility in the data, the information must be written in the code.
Data-Driven
The Data-Driven framework is based on a structure similar to that of Module Based, the difference is that it handles data inputs when entered by the user, without the need to have the information in the code.
For example, if you need to test a login, it is not necessary to go to the code and change the credentials manually, but to extract the information from an Excel file, databases, API, among others.
The advantages of Data driven are:
Compared to previous frameworks, the cost is considerably reduced, because the information is easier to manage.
Coverage increases, because it will be easier to cover different scenarios and test the application with different values.
Flexibility of execution.
The disadvantages of data driven are:
Additional effort to set up, configure and maintain data sources.
Proficiency in some programming language.
Keyword-Driven
The Keyword-Driven framework consists of performing actions in the code through a keyword. What it will do is to activate a certain action according to the procedure (step number), for example in the following image you will see that first a login will be executed, then a click on a button (clickButton) and so on.
The advantages of Keyword-driven are:
Flexibility in test creation, because you can use any combination of steps.
Reusability of code and, therefore, the maintenance cost is lower.
No knowledge of scripting is required, you only need to know what each keyword does.
The disadvantages of Keyword-driven are:
Increased difficulty as new keywords are introduced.
Learning complexity.
Hybrid (Data-driven + Keyword-driven)
The Hybrid framework consists of a combination of Data-driven and Keyword-driven, in which you have the information you want to use in an action determined by the keyword in a certain step (step number).
Behavior Driven Development
The Behavior Driven Development (BDD) framework is a development-driven development framework that contains a language that is easy for anyone to read. Typically, a natural Gherkin language consisting of three parts is used:
Given: gives us the preconditions of the test.
When: gives us the trigger of the action.
Then: allows us to validate with an acceptance criterion.
The advantages of BDD are:
There is greater compatibility between user stories and test cases.
Clarity in the test cases.
There is code reuse, because each statement has a reusable component.
It is Data-Driven, because it has a functionality called outline scenarios that allow information to be stored and used.
The disadvantages of BDD are:
Greater time dedication.
More planning time in the structure of the code and its sentences.
Knowledge of Gherkin or similar.
Contribution created with the contributions of: Andrés Guano.
Contributions 63
Questions 5
Sort by:
Want to see more contributions, questions and answers from the community?
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.
Aunque los temas abordados en la clase se enumeraron explicaron en su totalidad, faltaron ejemplos y casos de uso aplicados. Al ser un curso de automátización deberia ser mas práctico que teórico.
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
Want to see more contributions, questions and answers from the community?