Icono del sitio Alexander Andrade

Estrategia de automatización de pruebas: qué debemos automatizar

Diseñar e implementar una estrategia de automatización de pruebas puede ser abrumador. Hay varios puntos a considerar y al investigar, se hallará muchos puntos de vista a considerar. La forma en que se desarrolla e implementa una estrategia de automatización es única para las necesidades y habilidades de cada organización. En esta serie de artículos de tres partes, se proporcionarán algunas ideas sobre cómo diseñar e implementar estas estrategias.

Una parte extremadamente importante para determinar su estrategia de automatización es responder a la antigua pregunta sobre la automatización: ¿Qué debemos automatizar? En artículo se discute por qué no debe automatizar todo y se presentan algunas preguntas para ayudarte a determinar qué debes automatizar. 

Tabla de contenido: estrategia de prueba de automatización: qué debemos automatizar

  1. Capítulo 1 – Identificar los objetivos y responsables
  2. Capítulo 2 – ¿Qué debo buscar en una herramienta?
  3. Estás aquí → Capítulo 3 – ¿Qué debemos automatizar?

 Tal vez te interese el artículo Hoja de ruta para convertirse en un Automatizador de Pruebas.

 ¡Automatiza todo!

Independientemente de si estás comenzando a automatizar un proyecto nuevo o uno existente, nunca debes considerar automatizar todo, solo por el simple hecho de automatizar. Es tentador, lo sé. Pero veamos por qué eso no es una buena idea:

Vale la pena mencionar algunas cosas parecen atractivas de automatizar, desde el punto de vista del escenario, pero que no siempre funcionan bien cuando se implementan o no se pueden automatizar:

 ¡Automatiza lo que mas aporta valor!

Hemos hablado de por qué no deberías automatizar todo, ahora hablemos sobre qué deberías automatizar. Aquí hay algunas preguntas que puedes hacer para determinar que ques un candidato ideal para la automatización:

Pruebas unitarias vs. Pruebas de integración vs. Pruebas de UI / E2E

Una parte del análisis de qué y cómo automatizar es determinar en qué capa automatizar el escenario de pruebas. Muchos gurús de las pruebas han publicado su propia versión de la pirámide de automatización, pero aquí está la pirámide original como referencia:

Pirámide de pruebas de Mike Cohn

Esencialmente, la pirámide visualiza el conjunto de automatización total y define el porcentaje de pruebas o esfuerzo de aseguramiento por cada capa. Este porcentaje es basado en promedios y cada organización lo ajusta a sus necesidades particulares, pero siempre se debe tener en cuenta que la mejor prueba es aquella que entrega retroalimentación lo más antes posible.

Pruebas unitarias

Las pruebas unitarias constituyen la capa más grande de la pirámide. Es una prueba simple que se centra en una única unidad (un fragmento de código aislado, por ejemplo, una clase). Esta prueba no debe depender de ningún sistema externo, como una base de datos, configuraciones o incluso otras pruebas.

Pros Contras
  • Rápidas de escribir
  • Brinda a los desarrolladores comentarios inmediatos a medida que se ejecutan rápidamente
  • Brinda detalles específicos al desarrollador sobre el problema, ya que están contenidos en unidades individuales
  • Dado que son específicos de una unidad, se pasan por alto errores en la integración y las capas de la interfaz de usuario
Pros y contras de las pruebas unitarias

Para estas pruebas es muy común utilizar dobles de pruebas, mocks, stubs o espías. En este artículo podrás encontrar más información sobre estos: ¿Mock, Stub o Spy? ¿Cuál es la diferencia y cuándo debo usar cada uno?

 Tal vez te interesen los siguientes artículos relacionados:

Prueba de integración

La capa de pruebas de integración está destinada a aumentar el alcance de las pruebas e incluye pruebas de nivel de servicio o API. Estas pruebas se basan en la capa de pruebas unitarias, garantizando que las unidades de código se puedan integrar sin problemas. Esta capa también debe considerar cualquier prueba de contrato que pueda tener. Por ejemplo, cualquier integración de terceros con su aplicación.

ProsContras
  • Agrega una capa adicional de pruebas más allá de las pruebas unitarias
  • Más estable que las pruebas UI / E2E; tanto a la hora de desarrollar como de mantener pues hay menos cambios en esta capa
  • Ejecución más rápida; mucho más rápido que las pruebas de IU / E2E.
  • Si bien las pruebas de integración aumentan el alcance de las pruebas, no se centran en la capa de experiencia del usuario (UI)
Pros y contras de las pruebas de integración

Prueba de interfaz de usuario / E2E

La capa de prueba de la interfaz de usuario es importante, pero no debería constituir la mayor parte de sus pruebas. Esta capa se centra en la experiencia del usuario (UX) al garantizar que los flujos de la interfaz de usuario (UI) funcionen como se esperaba.

ProsContras
  • Garantiza que la experiencia del cliente esté intacta
  • Las herramientas de grabación y ejecución (record and play) pueden hacer que esta capa sea más fácil de automatizar
  • Si bien son más fáciles de automatizar requieren mucho más tiempo para diseñar y automatizar
  • Pruebas anémicas o poco resistentes, ya que la interfaz de usuario suele cambiar con frecuencia; mayor probabilidad de reportar falsos positivos
  • Los tiempos de ejecución son más largos. Incluso, algunas recomendaciones son cerrar la sesión y el navegador antes de cada ejecución.
Pros y contras de las pruebas de interfaz de usuario / E2E

Conclusión

Determinar qué escenario automatizar y qué capa automatizar requiere práctica y diligencia para asegurarse de que se está automatizando para agregar valor. Debes tener en cuenta cuánto está automatizando en el nivel de la interfaz de usuario. Resulta tentador y bastante fácil intentar llevar todo, fuera de las pruebas unitarias, a esa capa. Al final, dedicará más tiempo al mantenimiento y la ejecución que a la programación de nuevas funciones.

Las pruebas unitarias son importantes y pueden ser una buena forma de involucrar a los desarrolladores en el proceso de automatización. Las pruebas unitarias son también una buena manera de conseguir una rápida retroalimentación durante el tiempo de desarrollo de nuevas funcionalidades y prevenir situaciones antes de que lleguen a QA (Aseguramiento de la Calidad de Software).

Y finalmente, no automatices todo. Asegúrate de preguntarte si el escenario debería automatizarse. Si recién estás comenzando con la automatización en un proyecto existente, un buen lugar para comenzar es automatizar tu pila de pruebas de regresión.

Fuentes

Basado en Automation Test Strategy: Identify Your Goals and Ownership por Johanna South. 

Imagen por Firmbee.com en Unsplash.

Author: Alexander Andrade

Ingeniero de Sistemas, MBA y Especialista en Gerencia de Proyectos Tel: +57-317-241-5118
Salir de la versión móvil