Liderazgo en Pruebas: Herramientas de Ejecución de Pruebas
Nota del editor: Bienvenido a la serie Liderazgo en Pruebas del gurú y consultor en pruebas de software Paul Gerrard. La serie está diseñada para ayudar a testers con algunos años de experiencia—especialmente aquellos en equipos ágiles—a sobresalir en sus roles de líder y gestor de pruebas.
En el artículo anterior analizamos las herramientas que utilizarás regularmente como gestor de pruebas. En este artículo, nos centraremos más específicamente en las herramientas de ejecución de pruebas y qué se obtiene, y qué no, con ellas.
Suscríbete al boletín de The QA Lead para recibir una notificación cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Liderazgo en Pruebas de Paul, que recomendamos encarecidamente para profundizar en este y otros temas. Si lo haces, usa nuestro código de cupón exclusivo QALEADOFFER para obtener $60 de descuento en el precio completo del curso.
Automatización de pruebas (ejecución)
El tema de la automatización de pruebas (normalmente a través de una interfaz gráfica de usuario) ocupa un lugar destacado en la agenda de la mayoría de los testers y gestores de pruebas. Superficialmente, estas herramientas parecen muy prometedoras, pero muchas organizaciones que desean automatizar parte o la totalidad de sus pruebas funcionales encuentran problemas.
No entraremos en muchos detalles técnicos en este artículo, pero abordaremos algunos de los temas relevantes para los gestores de pruebas y de proyectos que necesitan crear un caso de negocio para la automatización. Veremos:
- Qué obtienes y qué no de las herramientas de ejecución de pruebas
- Automatización de pruebas de interfaz gráfica de usuario (GUI)
- Automatización de pruebas de API y servicios
- Pruebas de regresión
- Frameworks de automatización de pruebas
Es importante establecer expectativas realistas sobre lo que la automatización puede y no puede hacer, así que las próximas secciones pueden parecer algo pesimistas.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Qué obtienes y qué no de las herramientas de ejecución de pruebas
Ya sea que estés probando aplicaciones de escritorio de Windows, sitios web o dispositivos móviles, los principios de la automatización de pruebas, los beneficios y los obstáculos son similares. Lo que te ofrecen las herramientas es:
- Un robot incansable y, supuestamente, libre de errores que ejecutará los casos de prueba definidos que quieras, bajo demanda, tantas veces como desees.
- Una comparación precisa entre la salida y/o el resultado de las pruebas, con los resultados esperados preparados, al nivel de detalle que estés dispuesto a programar en la herramienta.
Lo que no obtienes es:
- Flexibilidad y respuestas ágiles ante anomalías, fallos o comportamientos dudosos.
- Los ojos y el pensamiento de un tester humano, capaz de tomar decisiones para explorar, cuestionar, experimentar y desafiar el comportamiento del sistema bajo prueba.
- Pruebas gratis. Por ejemplo, todavía tienes que diseñar los casos de prueba, preparar los datos y los resultados esperados.
- Aunque las herramientas de ejecución de pruebas ofrecen una variedad de funcionalidades, a menudo carecen de capacidades avanzadas de almacenamiento de datos. Para una solución más completa, quizás quieras explorar el mejor software de gestión de bases de datos disponible.
Analicemos el significado de estos beneficios y problemas.
Si eres un programador razonablemente competente, es sencillo implementar pruebas procedimentales, ejecutadas por humanos, como procedimientos automatizados en el lenguaje de scripts de tu herramienta para que la herramienta los ejecute con precisión.
Mientras el entorno y los datos utilizados por tu aplicación de prueba sean consistentes, puedes esperar que tus pruebas se ejecuten de manera confiable una y otra vez. Esta es la promesa evidente de la ejecución automatizada de pruebas.
Pero las pruebas automatizadas no simulan con exactitud lo que hacen los (buenos) testers al probar.
Una prueba ejecutada por una herramienta NO es equivalente a la misma prueba ejecutada por un humano.
Una prueba, si está guionizada, puede indicar al tester qué hacer. Pero los testers pueden mirar más allá de la simple comparación entre un resultado esperado y el resultado mostrado en una pantalla.
Los testers deben navegar hasta la ubicación de la prueba y estar atentos a comportamientos anómalos: la respuesta de los comandos; la velocidad de respuesta; la apariencia de la pantalla; el comportamiento de los objetos afectados por el cambio de estado de la aplicación.
El tester humano, al observar una anomalía, puede hacer una pausa, volver sobre sus pasos o profundizar en la aplicación o los datos antes de concluir si la aplicación funciona correctamente (o no) y decidir si continuar con la prueba guionizada, ajustar los datos y el script de la prueba, o seguir como estaba planeado.
Los humanos son flexibles mientras que las herramientas solo harán exactamente lo que les programes. En una transacción basada en pantallas, la herramienta introduce datos, hace clic en un botón y comprueba si aparece un mensaje o resultado mostrado, y eso es todo. Con los testers humanos, obtienes mucho más de lo que damos por sentado.
En principio, es posible programar una herramienta para que realice todas las comprobaciones que una persona hace instintivamente, pero tendrás que escribir mucho código y dedicar tiempo a depurar tus pruebas. Incluso entonces, no obtienes la capacidad humana de decidir qué hacer después: pausar, continuar, cambiar la prueba a mitad del proceso o investigar una anomalía más a fondo.
No hay ningún lugar donde la inflexibilidad de las herramientas sea más evidente que cuando deben reaccionar ante la pérdida de sincronización del script con el sistema bajo prueba. Puede que un resultado esperado no coincida, que el sistema se bloquee o que el comportamiento de la interfaz de usuario (por ejemplo, un cambio en el orden de los campos o un campo nuevo) difiera de lo que espera el script. ¿Qué hace la herramienta? Intenta continuar y se produce una avalancha de fallos o bloqueos del script.
Sí, puedes y deberías tener manejadores de eventos no planificados en tu script para detectar fallos de prueba. La pérdida de sincronización, las discrepancias entre el estado del sistema y los datos de prueba, los cambios en el orden de los campos, los campos añadidos o eliminados son cosas que el tester puede reconocer y actuar al respecto sin detener por completo la prueba. Las herramientas no pueden hacer esto sin que tú programes mucho más.
También existen desventajas al usar humanos para seguir pruebas guiadas por scripts. Los testers pueden obsesionarse con seguir el script y olvidar usar sus habilidades de observación. Podrían pasar por alto anomalías evidentes porque se concentran solo en seguir el guion. Este enfoque subóptimo es exactamente lo que obtenemos con la automatización de la ejecución de pruebas.
La adhesión ciega a los guiones de pruebas es una mala idea para los testers humanos, pero es lo mejor que podemos lograr con la automatización de pruebas.
En esta comparación entre testers que siguen guiones y herramientas que ejecutan pruebas, no hemos considerado lo que hacen los testers exploratorios. El enfoque exploratorio les da libertad de investigar y probar donde y como quieran.
Está claro que las herramientas no pueden simular esta actividad. Más importante aún, las herramientas no pueden delimitar, priorizar y modelar la funcionalidad y riesgos del sistema ni diseñar pruebas en consecuencia.
Los análisis y diseño de pruebas son actividades necesarias ya sea que la prueba la realice una persona o una herramienta.
Existen más limitaciones sobre lo que pueden hacer las herramientas de ejecución de pruebas:
- Las herramientas de ejecución de pruebas hacen exactamente lo que se les programa, ni más ni menos
- Normalmente las herramientas no realizan la construcción y configuración del entorno y la aplicación, ni la carga de datos de prueba
- Las herramientas no crean los casos o guiones de prueba, ni preparan los datos de prueba y resultados esperados
- Las herramientas no pueden tomar decisiones meditadas cuando ocurren eventos inesperados.
Para optimizar tus procesos de ejecución de pruebas, integrarlos con un sólido software de gestión de pruebas puede ofrecer flujos de trabajo optimizados e informes mejorados.
Automatización de Pruebas en Interfaces Gráficas de Usuario (GUI)
Han pasado unos veinticinco años desde que las herramientas de automatización de pruebas GUI llegaron al mercado, pero el número de implementaciones fallidas de estas herramientas sigue siendo alto. Esto se debe principalmente a que las expectativas de la automatización son demasiado grandes, y las herramientas utilizadas sin disciplina nunca las cumplen.
Las herramientas de automatización de pruebas GUI tienen fama de ser fáciles de usar como productos, pero difíciles de gestionar cuando las aplicaciones bajo prueba (y, por tanto, los scripts de prueba) deben cambiar. Estas herramientas son muy sensibles a los cambios en la interfaz de usuario. Cambios de ubicación, orden, tamaño y la adición o eliminación de objetos en pantalla pueden afectar los scripts. Cambios más técnicos, como el renombramiento de objetos en pantalla o la modificación de librerías GUI ‘invisibles’ y embebidas, también provocan problemas.
La automatización de pruebas GUI funciona mejor cuando existe disciplina respecto a:
- El proceso de desarrollo y cuando los cambios y lanzamientos se gestionan cuidadosamente. Por ejemplo, los cambios se analizan respecto a su impacto y se notifican a los testers.
- El enfoque de desarrollo de scripts de prueba. Los ingenieros de automatización de pruebas experimentados adoptan convenciones sistemáticas de nomenclatura, estructuras de carpetas, componentes modulares y reutilizables, técnicas de programación defensiva, y más.
La creación de scripts de automatización de pruebas es una tarea que requiere más que conocimientos básicos de programación y, sobre todo, experiencia en automatización y en el uso de la herramienta. Cuando las pruebas se automatizan a gran escala, también se requieren habilidades de diseño.
No importa cómo los proveedores describan las herramientas – “sin scripts”, “usables por personas sin conocimientos de programación” o “los usuarios también pueden automatizar” – todavía necesitas una mentalidad de programador, habilidades de diseño y un enfoque sistemático.
Automatización de Pruebas de API y Servicios
Cuando existen componentes o funcionalidades desplegados como servicios, llamados por clientes ligeros o móviles, las pruebas se realizan usando una API o mediante llamadas a servicios. Este modelo de pruebas se lleva a cabo tanto con código personalizado escrito por desarrolladores como mediante herramientas específicas para pruebas de API o servicios. En cualquier caso, el enfoque habitual es automatizar las pruebas de una manera u otra.
Debido a que la API está ‘más cerca’ del código a probar, las pruebas pueden estar mucho más enfocadas en la funcionalidad que se quiere verificar. Sin duda, se pueden evitar las complejidades de la navegación a través de la interfaz de usuario y las pruebas mediante la propia IU. Por este motivo, la regla general es:
Si la funcionalidad que se está probando (a nivel de código o componente) puede verificarse mediante una llamada a una función, una API o un servicio, la automatización será más fácil – y se recomienda.
Probar a través de la API tiene ventajas notables.
- Aunque tendrás que utilizar o escribir código, las propias pruebas serán mucho más fáciles de aplicar (no hay una interfaz de usuario de la que preocuparse).
- Una vez que una llamada API está automatizada, solo se trata de tabular el rango de casos de prueba que quieres aplicar. No hay límite para la cantidad de pruebas que puedes realizar.
- Las pruebas basadas en API suelen ejecutarse mucho más rápido, lo que hace que este estilo de pruebas sea muy adecuado para enfoques de entrega continua, donde la canalización de despliegue está altamente automatizada y necesita ser rápida para responder.
La ‘pirámide de automatización de pruebas’ (una búsqueda en Google mostrará cientos de ejemplos gráficos) se ha adoptado casi universalmente para recomendar que los esfuerzos de automatización de pruebas se centren más en las pruebas de desarrollador o API que en la interfaz gráfica de usuario.
- Utiliza pruebas de IU cuando sea necesario ejercitar el flujo de trabajo del usuario, pero en baja cantidad, porque son costosas y pueden ser lentas de ejecutar.
- Utiliza llamadas de API o servicios cuando la funcionalidad bajo prueba se puede aislar y cuando la rapidez y facilidad de automatización sean esenciales.
Pruebas de regresión
El uso clásico de las herramientas automatizadas es en la ejecución de pruebas de regresión. Estas pruebas se ejecutan una vez y se confía en que sean representaciones precisas del comportamiento esperado. Cuando se producen cambios en el código de la aplicación bajo prueba, en las bibliotecas reutilizables asociadas o en el entorno de prueba, estas pruebas proporcionan cierta confianza de que la funcionalidad requerida no se ha visto afectada negativamente por el cambio.
Puedes imaginar las pruebas automatizadas como un molde en el que encaja el sistema a probar. Por supuesto, las pruebas deberían ‘superar’ todas las verificaciones que se ejecutaron previamente. Al volver a ejecutarlas, intentas demostrar la equivalencia funcional de la nueva versión del software respecto a la anterior. Hay algunos principios sencillos que debes seguir:
- En primer lugar, las pruebas y comprobaciones que se llevan a cabo deben seleccionarse para darte confianza de que no existen cambios de comportamiento no deseados. Estas pruebas actúan como una ‘alarma’ para detectar diferencias de comportamiento.
- Cuando se corrigen errores o se realizan otros cambios de software, puede haber casos de comportamientos que se modifican (correctamente) pero que, al ser encontrados por tus pruebas, fallarán una comprobación. O bien tienes que modificar tus pruebas de antemano o dejar que fallen y corregirlas después. A veces, es más rápido descartar por completo las pruebas que fallan y crear pruebas nuevas desde cero que las reemplacen. En cualquier caso, estas pruebas modificadas deben ejecutarse hasta completarse y aprobar todas las verificaciones.
- Si el sistema a probar no es estable, tiene muchos errores o sufre grandes cambios entre versiones, puede que no sea viable mantener económicamente un conjunto de pruebas automatizadas. Aunque la funcionalidad del sistema no cambie, es posible que la interfaz de usuario aún esté evolucionando – una interfaz inestable dificulta también el mantenimiento de la automatización. El coste de investigar fallos y mantener las pruebas podría superar su utilidad. Sería prudente probar manualmente las partes menos estables del sistema hasta que se estabilicen.
Probar mediante la interfaz de usuario puede ser engorroso, costoso y lento de ejecutar en ocasiones. Antes de embarcarte en la automatización de pruebas gráficas, o incluso de automatizar un solo script, conviene considerar si probar la funcionalidad clave resultaría más fácil, rápido y económico usando una API.
El uso clásico de las herramientas automatizadas es en la ejecución de pruebas de regresión. Para asegurarte de que utilizas las herramientas más eficaces para esto, consulta nuestra lista de las mejores herramientas de pruebas de software
Frameworks de automatización de pruebas
Los frameworks de pruebas son una parte esencial de cualquier proceso de pruebas automatizadas exitoso. Pueden considerarse como un conjunto de directrices para crear y diseñar casos de prueba. Utilizarlos puede aumentar la velocidad y eficiencia del equipo de pruebas, mejorar la precisión de las pruebas, reducir riesgos y disminuir los costes de mantenimiento. Ahora veremos dos de ellos.
Al hablar de frameworks de automatización de pruebas, es fundamental considerar el papel de las herramientas de automatización QA para construir una estrategia de pruebas eficaz.
Frameworks de pruebas unitarias
Los frameworks de pruebas unitarias existen desde hace años y son ampliamente utilizados por los programadores para probar su código. Las pruebas de los desarrolladores suelen estar bastante localizadas; al fin y al cabo, normalmente verifican solo un componente con las interfaces a otros componentes o bases de datos simuladas o sustituidas. Así, aunque las pruebas unitarias necesitan pasos de preparación y limpieza antes y después de ejecutarse, estas tareas tienden a limitarse a las pruebas de un solo componente. Habría conjuntos de pruebas separados para cada componente.
Las pruebas unitarias creadas por los desarrolladores suelen estar bajo control de versiones y se gestionan en paralelo con el código de los componentes. Normalmente, los sistemas de Integración Continua toman el código fuente y todas las pruebas unitarias y las ejecutan después de cada confirmación de nuevo código y/o pruebas. Todos los desarrolladores ven el resultado de estas pruebas, por lo que un fallo en una prueba en CI se vuelve muy visible. Arreglar las pruebas y el código que fallan es una prioridad alta en los equipos que utilizan CI de esta manera, para que la última versión del sistema pase todas las pruebas de CI siempre.
Frameworks de Automatización de Pruebas de Integración y de Sistema
En los últimos años, las herramientas de pruebas de GUI se han integrado con herramientas de CI usando dispositivos virtualizados de prueba, entornos y ejecución a través de interfaces de línea de comandos. Muchas organizaciones han podido integrar completamente la ejecución de pruebas unitarias, a nivel de API y de GUI mediante servicios de Integración Continua.
Sin embargo, muchos equipos de pruebas aún operan sus propios entornos de prueba, separados del desarrollo o de los servicios de CI. Estos equipos tienden a construir sus propios frameworks de automatización de pruebas porque las herramientas de CI están demasiado orientadas al desarrollador o las herramientas propietarias son inadecuadas.
Las pruebas de GUI tienden a implementar pruebas de extremo a extremo o recorridos de usuario utilizando diferentes aplicaciones, dispositivos de hardware y entornos. Estas pruebas necesitan configurar sin problemas entornos de prueba integrados y datos de prueba preparados en diferentes plataformas, lo que requiere procedimientos privilegiados, complejos y entornos técnicos variados para operar. La gran mayoría de los equipos que utilizan automatización de pruebas de GUI construyen sus propios frameworks de automatización únicos, pero eficaces.
Los frameworks de automatización de GUI varían en sofisticación, desde herramientas similares a las pruebas unitarias hasta instalaciones complejas y completas que deben gestionar entornos, compilaciones de aplicaciones, grandes cargas de datos de prueba, mensajería y sincronización entre plataformas y entornos, y mensajes y notificaciones a los miembros del equipo.
Algunas herramientas propietarias vienen con utilidades o entornos para gestionar, ejecutar e informar sobre conjuntos de pruebas automatizadas. Estas tienen un valor variable, por lo que muchas organizaciones escriben sus propios frameworks de automatización de pruebas para extender su funcionalidad. En los últimos años, el alcance de los frameworks de automatización ha crecido, y ya no existe una definición única o simple, así que ahora veremos lo que los frameworks de automatización de pruebas pueden hacer por los equipos de software.
Un framework de automatización de pruebas amplía la funcionalidad de los motores de ejecución de pruebas.
Configuración de la Suite de Pruebas
El framework integra las pruebas automatizadas en colecciones significativas, o conjuntos, de pruebas. Estas colecciones son configurables, ya que las pruebas pueden ejecutarse en una jerarquía de secuencias, grupos o selecciones arbitrarias. Estas herramientas pueden incluir funciones para conducir pruebas con datos utilizando tablas preparadas de datos de prueba. Este es el tipo de framework más sencillo: las herramientas populares suelen ofrecer alguna forma de configuración de suites de pruebas.
Preparación y Limpieza
El framework maneja todas las actividades de preparación y limpieza para una sola prueba, una colección o toda la suite. La preparación puede implicar crear entornos de prueba desde cero, configuraciones completas y precarga de bases de datos de prueba y otras fuentes de datos. La limpieza puede implicar la eliminación de datos de prueba o el restablecimiento o borrado parcial o total de entornos. El framework puede integrarse con herramientas de orquestación de pipelines y estar controlado por ellas.
Manejo de Excepciones
Un fallo en cualquier prueba —ya sea en el sistema bajo prueba o una pérdida de sincronización— puede manejarse de manera consistente, informando del evento y generalmente permitiendo que el resto de las pruebas de esa colección continúen ejecutándose. El framework puede programarse para gestionar fallos en checkpoints de pruebas, pérdida de sincronización, tiempos de espera de ejecución y otros resultados seleccionados de pruebas, cada uno con procedimientos propios.
Registro y Mensajería
El framework registra la ejecución de las pruebas y el estado de ejecución de manera uniforme en todas las colecciones. El framework puede activar informes desde las herramientas que ejecutan las pruebas o proporcionar un registro homogéneo de toda la preparación, ejecución y limpieza de las pruebas. El framework puede interactuar con bots de ChatOps para informar al equipo sobre excepciones y permitir a los miembros del equipo pausar, detener, repetir o reiniciar suites de pruebas.
Abstracción de Pruebas con Lenguaje Específico de Dominio
Han surgido en el mercado dos tipos distintos de frameworks que abstraen el código de ejecución de pruebas hacia modelos o texto humanamente legible o no técnico:
- Los frameworks dirigidos por palabras clave permiten definir pruebas usando palabras clave. Las llamadas a las funciones del motor de ejecución se implementan como comandos similares al inglés con marcadores de posición para parámetros o datos. Los módulos reutilizables definidos por el usuario pueden crearse y llamarse utilizando comandos en texto plano de la misma forma. Existen frameworks para todo tipo de interfaces, incluyendo GUI, servicios, APIs, intérpretes de línea de comandos, etc. Los scripts pueden probar funcionalidades en diferentes sistemas operativos y dispositivos.
- Los frameworks de Desarrollo Guiado por Comportamiento (BDD) permiten que las historias y escenarios (ejemplos) que describen el comportamiento de las funcionalidades se capturen usando un lenguaje específico de dominio (DSL). El lenguaje más popular es el llamado Gherkin, que utiliza la estructura “dado ... cuando ... entonces ...” para registrar ejemplos. "Dado/cuando/entonces" representan de manera efectiva las precondiciones, los pasos y las postcondiciones de los casos de prueba. Las herramientas BDD convierten el texto dado/cuando/entonces en ‘llamadas de pasos’ en un lenguaje de programación. El desarrollador (o tester) debe implementar los ‘fixtures’ o código para hacer llamadas a un motor de ejecución de pruebas. De este modo, el lenguaje de un requerimiento (la historia) puede conectarse directamente con el código de ejecución de texto.
Frameworks basados en modelos
En este caso, las herramientas permiten crear un modelo del sistema bajo prueba. Este puede derivarse automáticamente de una página web en la que la herramienta escanea el HTML, detecta los formularios y campos, y construye un modelo del cual se pueden generar automáticamente o seleccionar por el tester los caminos a través de los formularios. Los mapas de objetos para aplicaciones móviles u otros dispositivos inteligentes también pueden construirse manualmente. Utilizando los caminos a través del mapa de objetos, se hacen llamadas a las funciones del motor de ejecución de pruebas de manera similar a las herramientas BDD y de palabras clave. En principio, las pruebas pueden construirse gráficamente sin código. Las herramientas en este ámbito son relativamente nuevas y están mejorando rápidamente. Se espera que su uso se acelere en el futuro.
Suscríbete al boletín de The QA Lead para recibir notificaciones cuando se publiquen nuevas partes de la serie. Estas publicaciones son extractos del curso Leadership In Test de Paul, el cual recomendamos ampliamente para profundizar en este y otros temas. Si te animas, utiliza nuestro código exclusivo QALEADOFFER para obtener $60 de descuento en el precio total del curso.
Lectura relacionada: 10 MEJORES HERRAMIENTAS DE MONITOREO DE SERVIDORES WEB