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.
A esta clase le faltó. Quien hace pruebas mayormente funcionales tiene que saber de código, y aquí en cada framework solo se menciona por encima si se usa código o no. Se omiten cosas muy relevantes que te dejan perdido si estás empezando en pruebas. ¿Cómo se trabajan con estos frameworks? ¿Dónde se descargan? ¿Qué tipos de lenguajes de programación usan? Digo sé que escapan al alcance del curso, pero sería mejor mencionarlas como nota al pie, y así ni se pierden los que no saben y ni se desatiende los que tienen curiosidad.
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:
Al igual que hay infinidad de software con particularidades únicas de negocio y features.. como un APP de fintech o una pagina e-comerce. tiene que haber distintas tools para automatizar sus pruebas
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.
Estaba en la misma situacion, asi que busque y esta pagina me ayudo a entender un poco de que va todo (aunque solo hablan del Framework Data Driven), espero que te ayude tambien
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:
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.
