Está en la página 1de 25

AUTOMATIZACIÓN DE

PRUEBAS
En las pruebas de software, la automatización de pruebas consiste en el uso de software
especial (casi siempre separado del software que se prueba) para controlar la ejecución de
pruebas y la comparación entre los resultados obtenidos y los resultados esperados.1​ La
automatización de pruebas permite incluir pruebas repetitivas y necesarias dentro de un
proceso formal de pruebas ya existente o bien adicionar pruebas cuya ejecución manual
resultaría difícil.
Algunas pruebas de software tales como las pruebas de regresión intensivas de bajo nivel
pueden ser laboriosas y consumir mucho tiempo para su ejecución si se realizan manualmente.
Adicionalmente, una aproximación manual puede no ser efectiva para encontrar ciertos tipos
de defectos, mientras que las pruebas automatizadas ofrecen una alternativa que lo permite.
Una vez que una prueba ha sido automatizada, esta puede ejecutarse repetitiva y rápidamente
en particular con productos de software que tienen ciclos de mantenimiento largo, ya que
incluso cambios relativamente menores en la vida de una aplicación pueden inducir fallos en
funcionalidades que anteriormente operaban de manera correcta. Existen dos aproximaciones a
las pruebas automatizadas
Pruebas de regresión

Cualquier tipo de pruebas de software con el objeto de descubrir errores (bugs), carencias de
funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del
software, causados por la realización de un cambio en el programa. Se evalúa el correcto
funcionamiento del software desarrollado frente a evoluciones o cambios funcionales. El
propósito de éstas es asegurar que los casos de prueba que ya habían sido probados y fueron
exitosos permanezcan así. Se recomienda que este tipo de pruebas sean automatizadas para
reducir el tiempo y esfuerzo en su ejecución.
Pruebas manejadas por el código: Se prueban las interfaces públicas de las clases, módulos o
bibliotecas con una variedad amplia de argumentos de entrada y se valida que los resultados obtenidos
sean los esperados.

Pruebas de Interfaz de Usuario: Un marco de pruebas genera un conjunto de eventos de la interfaz de


usuario, tales como teclear, hacer click con el ratón e interactuar de otras formas con el software y se
observan los cambios resultantes en la interfaz de usuario, validando que el comportamiento observable
del programa sea el correcto.

La elección misma entre automatización y ejecución manual de pruebas, los componentes cuya prueba
será automatizada, las herramientas de automatización y otros elementos son críticos en el éxito de las
pruebas, y por lo regular deben provenir de una elección conjunta de los equipos de desarrollo, control de
calidad y administración. Un ejemplo de mala elección para automatizar, sería escoger componentes
cuyas características son inestables o su proceso de desarrollo implica cambios continuos.
Pruebas manejadas por el código

En el desarrollo contemporáneo de software existe una tendencia creciente a usar Frameworks


como los denominados XUnit (por ejemplo JUnit y NUnit) que permiten la ejecución de
pruebas unitarias para determinar cuándo varias secciones del código se comportan como es
esperado en circunstancias específicas.
La automatización de pruebas es una característica clave del desarrollo ágil de software en
donde se le conoce como "desarrollo guiado por pruebas". En ellas, las pruebas unitarias se
escriben antes que el código que genera la funcionalidad. Solo cuando el código pasa
exitosamente las pruebas se considera completo.
Pruebas de Interfaz de Usuario

Muchas herramientas de automatización de pruebas proveen características para grabar y


reproducir acciones del usuario para posteriormente ejecutarlas un número indefinido de
veces, comparando resultados obtenidos con resultados esperados. La ventaja de esta
aproximación a la automatización es que requiere de menos desarrollo de software, sin
embargo el confiar en estas características del software lo hace menos confiable en la medida
que muchas veces dependen de la etiqueta o posición del elemento de interfaz, y, al cambiar, el
caso de prueba debe ser adaptado al cambio o probablemente fallar. condiciones.
Automatizar pruebas de software: ¿Cuándo
y por qué?
Automaticemos las pruebas tanto como sea posible”. Eso siempre suena como una buena idea,
¿verdad? Es la forma en que va el mundo en general, ¿no? El ejercicio de automatizar pruebas
de software puede ser un gran elemento potenciador de la productividad, pero solo en ciertos
contextos.

En esta entrada, presentamos junto a Alejandro Berardinelli un enfoque para la automatización


de pruebas, con el objetivo de reconocer su viabilidad de acuerdo con el contexto del proyecto.
Identificar el contexto del proyecto

Es muy útil para un tester comprender qué es la automatización y tener claridad de cuando
algo es automatizable. Asimismo, debe tener en cuenta cómo pueden optimizar su trabajo, ya
sea colaborando con otros colegas, otros desarrolladores o animándose a probar una
herramienta de automatización.

Abordaremos algunos conceptos que son fundamentales cuando aún no tiene experiencia con
la automatización. También evaluaremos su importancia y beneficios, en relación con las
pruebas manuales.
¿Por qué automatizar pruebas de software?

Históricamente, la automatización surgió para reducir el esfuerzo humano requerido en


actividades que podrían ser replicadas por un sistema o máquina programable.

Al automatizar pruebas de software se persigue el objetivo de simplificar el trabajo


dispendioso, repetitivo o complejo, haciéndolo efectivo y más productivo.

De esta manera, es posible ahorrar energía, tiempo y costos, al tiempo que libera a las personas
para que se concentren en otras tareas
Automatización de esfuerzos manuales

En el desarrollo de software, esta práctica puede abordarse de la misma manera mediante la


automatización de ciertos esfuerzos que se realizan manualmente. Los pasos seguidos por las
personas se traducen en secuencias de comandos repetibles, para que puedan concentrar su
energía en otras tareas específicas que proporcionan un mayor valor y reducen los tiempos de
ejecución.

En algunos casos, la automatización nos permite realizar pruebas que un humano no podría,
especialmente teniendo en cuenta la limitación del número de ejecuciones que podemos hacer
en un determinado período de tiempo.
¿Cuándo algo se considera automatizable?

Esta suele ser una de las preguntas más comunes entre los testers. Y es que saber cuándo
automatizar pruebas de software implica evaluar la inversión potencial, el enfoque, los
beneficios y lo que es más importante, el conocimiento actual del proceso manual.

En primer lugar, tenemos que entender completamente y convertirnos en expertos en el


proceso manual, y solo entonces es posible automatizar.

El conocimiento completo del proceso manual es el pilar para saber cuándo algo es
automatizable, lo que implica que las pruebas manuales no son completamente sustituibles.
(Frecuentemente hay un debate sobre la muerte inminente de las pruebas manuales,
¡simplemente no pueden desaparecer!)
Mitos de la automatización

 Automatizar pruebas de software tiene sus ventajas y desventajas. Depende del proyecto,
el tiempo, el costo, la calidad y la metodología.

 Basado en lo anterior, otro aspecto importante es que más allá de automatizar o no


automatizar, se debe comprender el contexto.

 Además, hay que considerar que todo lo que hace se basa en cumplir los objetivos de la
mejor manera posible, seleccionando y aplicando los métodos, herramientas y habilidades
apropiadas.
Entre los mitos comunes sobre la
automatización de pruebas encontramos
 Es posible automatizar todo.
 La automatización siempre conduce a una mejor calidad de software.
 Las pruebas automatizadas son mejores que las manuales.
 La automatización trae un rápido retorno de la inversión.
Desde luego, pueden haber ocasiones en que uno de estos mitos sea realmente cierto, pero eso
sería una excepción a la regla.
Según Context-Driven Testing School, los siguientes siete principios ayudan a comprender el objetivo del
testing, ya sea manual o automatizado:

 El valor de cualquier práctica depende de su contexto.


 Hay buenas prácticas en contexto, pero no hay “buenas prácticas”.
 Las personas, trabajando juntas, son la parte más importante del contexto de cualquier proyecto.
 Los proyectos no son estáticos y a menudo toman caminos impredecibles.
 El producto es una solución. Si el problema no se resuelve, el producto no funcionará.
 El software testing es un proceso intelectual desafiante.
 Solo a través del juicio y la habilidad, practicados cooperativamente durante todo el proyecto, podremos
hacer las cosas correctas en el momento adecuado para probar nuestros productos de manera efectiva.
Manual vs Automatizado

Al comenzar, es posible que queramos automatizar todo, pero el costo de desarrollar y


mantener los scripts para las pruebas automatizadas no es algo que deba tomarse a la ligera.

Cuando un proyecto apuesta por automatizar pruebas de software, idealmente debería tener
una base sólida comenzando con los casos de prueba unitarios, evitando tantos errores como
sea posible.

Esta automatización debe contar con una retroalimentación inmediata y continuar


sucesivamente a las diferentes capas. De esta forma, las pruebas manuales y exploratorias son
más valiosas en el nivel de la interfaz de usuario, centrándose en aquellas pruebas que no son
posibles de automatizar.
Este concepto lo explica detalladamente la pirámide de automatización de pruebas
de Mike Cohn:
Herramientas para automatizar Pruebas de
Software?
 Esta actividad puede ser una de las más complejas de analizar inicialmente, dado el
número de herramientas disponibles.

 No obstante, la decisión tendrá que considerar el proyecto, el presupuesto, el conocimiento


y la experiencia de los involucrados.

 Primero, las herramientas que tenemos a nuestro alcance varían en sus limitaciones y
posibilidades. Por lo que para seleccionar la herramienta correcta para automatizar una
prueba, hay que tener claridad de los requisitos que deben cumplirse para continuar el
análisis de costo-beneficio de su uso.
Herramientas open source comerciales y
personalizadas
Selenium
 Es una herramienta de código abierto, ampliamente aceptada en todo el mundo para probar
aplicaciones web en diferentes navegadores y plataformas.

Appium
 Es otra herramienta open source basada en Selenium que se puede emplear para
automatizar las pruebas, principalmente en dispositivos móviles para iOS y Android.

Cucumber
 Cucumber es parte del enfoque BDD (Behavior Driven Development) y su principal
ventaja es la facilidad de uso, ya que es muy intuitiva.
Ghost Inspector
 Lo más interesante de Ghost Inspector es que nos permite automatizar sin saber codificar,
lo que la convierte en una herramienta ideal para principiantes. Esta herramienta solo
permite 100 ejecuciones gratuitas por mes.

GXtest
 En Abstracta desarrollamos GXtest para permitir la automatización de aplicaciones
desarrolladas con Genexus de una manera simple (la única de su tipo). Y eso no es todo,
también permite integrar pruebas en un modelo CI / CD.

También podría gustarte