Director Asociado - Tecnología, Automatización Inteligente (IAT)
El paradigma de la automatización de pruebas siempre sigue “evolucionando”. Las organizaciones han sido testigos y parte de esta evolución a lo largo de los años. Los equipos de pruebas forman parte del club “Been there, done that” (ya lo he hecho) cuando se trata de técnicas convencionales de automatización de pruebas. Algunos de nosotros estamos literalmente sentados en el montón de scripts de prueba automatizados, sintiéndonos nerviosos, inseguros de si el equipo de proyecto tiene una cobertura de prueba adecuada. Los ingenieros de automatización siempre han automatizado los casos de prueba y han actualizado los scripts para los cambios en los casos de prueba, han creado nuevos casos de prueba y han eliminado los scripts de prueba que ya no son válidos. Los equipos se esfuerzan por mantener diferentes versiones de casos de prueba y scripts de prueba; la lista es interminable.
La gente se esfuerza por identificar y programar las pruebas que deben ejecutarse y hacer frente al aumento exponencial de la demanda de pruebas en diversos entornos. Luego hay un grupo que siempre dice: “Está automatizado... ¡Por qué no ejecutarlo todo!”.
Hoy en día, los retos a los que se enfrentan los gestores de pruebas no son nuevos, pero se están volviendo críticos con la velocidad a la que están cambiando las cosas. El tiempo de respuesta se está reduciendo como nunca, y todo el mundo se esfuerza por introducir la innovación y la IA en la automatización de las pruebas.
A lo largo de los años, los enfoques tradicionales de automatización de pruebas han aportado beneficios, pero con un enorme coste inicial que depende de múltiples factores como la infraestructura, las herramientas, las tecnologías y los conjuntos de habilidades. Estamos asistiendo a un cambio de los métodos de automatización de pruebas convencionales que utilizan casos/historias de prueba como base para crear la automatización de pruebas a un enfoque de pruebas basado en el “modelo”.
Aunque la transición no es difícil, hay una mayor necesidad de cambiar la mentalidad y obtener un mayor nivel de comodidad con la automatización de pruebas basada en modelos. Los gestores de pruebas que están acostumbrados a mantener vastos conjuntos y versiones de casos de prueba pueden sentirse un poco incómodos al ver un modelo y ningún caso de prueba.
Ya existen herramientas para crear el modelo de un sistema, y muchas de ellas ofrecen un mecanismo para ejecutar un modelo que cubra diferentes rutas y puntos de verificación. Con unas pocas iteraciones y práctica, se pueden crear y ejecutar modelos para comprender cómo y qué tipos de casos de prueba virtuales se desarrollan e implementan a partir del modelo.
La MBT es una técnica de pruebas en la que se define un modelo abstracto que describe el comportamiento de un software y, a continuación, se utiliza este modelo para probar el software real basándose en las predicciones de las rutas.
El traje de prueba abstracto actúa como una base sobre la que se deriva el conjunto de pruebas ejecutables. El conjunto de pruebas ejecutables (scripts de automatización) mapeado con los casos de prueba abstractos puede comunicarse directamente con el SUT (sistema bajo prueba).
Un modelo es una representación gráfica del comportamiento del sistema con estados y acciones. El modelo comienza con las condiciones iniciales y termina con las condiciones de salida. El comportamiento puede describirse en términos de secuencias de entrada, acciones, condiciones, salida y flujo de datos de la entrada a la salida.
Un modelo se interpreta o se traduce en un sistema de transición de estados o automatización de estados finitos. El diagrama de transición de estados está representado por el modelo de la aplicación, un grafo dirigido en el que los nodos representan los estados de la aplicación y las aristas representan las transiciones.
Un modelo típico puede representarse de diferentes formas en función de la herramienta seleccionada. A continuación se muestran algunos ejemplos:
El modelo genera solo escenarios de usuario de rutas posibles basadas en las condiciones iniciales y de salida. Las rutas de prueba incluyen todas las permutaciones y combinaciones posibles de pasar por los nodos intermedios entre las condiciones iniciales y de salida. A diferencia del enfoque tradicional de automatización de pruebas, las rutas de prueba no son condicionales en scripts de prueba escritos. La ruta tomada durante la ejecución es aleatoria y depende del algoritmo del motor de ejecución, considerando varios criterios como “porcentaje de cobertura”, “peso”, etc.
Con la aparición de la automatización de pruebas basada en modelos en el horizonte, las posibilidades de las ideas de automatización de pruebas futuristas comenzaron a hacer rondas de discusiones. Algunos de nuestros clientes, las empresas de productos, pudieron darse cuenta inmediatamente de las ventajas y beneficios de la MBT en entornos en constante cambio.
MBT ha ayudado a la gestión de pruebas a reducir drásticamente los esfuerzos de los casos de prueba, la generación de scripts, la revisión y la reelaboración. Sin embargo, una de las principales ventajas de utilizar MBT es la cobertura de las pruebas. Con el enfoque convencional de automatización de pruebas, la cobertura está influida por el número de pruebas manuales creadas o el número de casos de prueba automatizados.
Existe el riesgo de que se pierdan múltiples escenarios de prueba al redactar los scripts de prueba manuales o de automatización. En el caso de los modelos, un ingeniero de pruebas o un analista de negocio define todos los estados y acciones posibles para un escenario de pantalla o caso de uso. El porcentaje de cobertura de las pruebas aumenta drásticamente, ya que las pruebas se generan automáticamente para todas las combinaciones posibles de estados y acciones entre los estados inicial y de salida.
Existen inmensas posibilidades de mejorar aún más la cobertura de las pruebas con la automatización de pruebas basada en modelos utilizando IA/ML.
Los casos de prueba siguen procedimientos establecidos en el enfoque de pruebas convencional, donde el juicio humano es la base. Para cubrir diferentes rutas o procedimientos, hay que crear nuevas pruebas. Sin embargo, en MBT, la mayoría de las rutas se derivan de los modelos, que están estrechamente relacionados con los requisitos y con los scripts o conjuntos de pruebas generados automáticamente. La diferencia es evidente si vemos los siguientes flujos de trabajo.
El enfoque convencional exige un esfuerzo considerable para la automatización de las pruebas, incluso para un ligero cambio en los requisitos empresariales. Sin embargo, la actualización del respectivo componente del modelo mediante MBT incorpora los cambios rápidamente. Para los profesionales de las pruebas, MBT es una metodología convincente con los siguientes beneficios:
Director Asociado - Tecnología, Automatización Inteligente (IAT)
Aman Kumar es un arquitecto de automatización de pruebas senior con más de 16 años de experiencia en la provisión de soluciones de automatización de pruebas de extremo a extremo utilizando herramientas y tecnologías de licencia de código abierto & para Web, GUI, Móvil, API, Visión & Voz a través de diferentes dominios. Su interés incluye la exploración y el desarrollo de soluciones de automatización inteligentes utilizando técnicas de IA/ML.
Suscríbase para estar al día de las últimas novedades del sector, incluidas las perspectivas de la industria y las capacidades de las soluciones innovadoras