1.4. Las pruebas automatizadas.
 
  

Muchos habrán escuchado sobre las pruebas de regresión, las automatizaciones no están solamente destinadas a este tipo de pruebas sino que puede ser la opción más popular.

Estas pruebas califican como un subconjunto de pruebas seleccionadas para ser ejecutadas de forma diaria o antes de cada nueva iteración del producto para verificar que no haya sido afectado por ningún problema y haya sufrido una regresión.

El simple hecho es que necesitamos chequear el sistema que estamos probando para que no sufra regresiones, cuando menciono regresiones hago referencia a que si existe una versión n y en la próxima iteración se avanza a las versión (n + 1) y se encuentras fallos, nos vemos forzados a volver a la versión anterior. Ese es el motivo por el cual se realizan las pruebas de regresión.

Las pruebas no se limitan a verificar que los bug relacionados con la iteración anterior se hayan solucionado y todo este funcionando como antes, sino que también es correcto decir que las funcionalidad que anteriormente tenían un correcto funcionamiento sigan funcionando con normalidad y sin ninguna alteración.

Cada vez que se realice una iteración en el ciclo de desarrollo se debe ejecutar la suite seleccionada que contienen las pruebas para verificar el correcto funcionamiento del sistema.

Así como menciono en el artículo “1.0 Introducción a las pruebas automatizadas”,

las pruebas manuales que se realizan pueden volverse muy largas, tediosas o complejas, las automatizaciones aseguran que las ejecuciones que se realicen sean consistentes en todas sus iteraciones,  las personas pueden generar distracciones y puede que se pierda la rigurosidad en la prueba.


Con respecto a las pruebas automatizadas:

Cuando se automatiza puede que se encuentre una gran cantidad de bugs al momento de trabajar con los test case, cuando se automatiza se explora las funcionalidades, se prueba con juegos de datos diferentes, etc. Esto hace que el creador de las pruebas automatizadas este en contacto con la funcionalidad durante un tiempo estimado prestando atención a diferentes detalles y eso hace que se realice un trabajo de testing excautivo y esto hace que uno se familiarice con la funcionalidad a probar.

La automatización de pruebas posee varias ventajas, entre ellas la mejora de la calidad ya que existe menos errores del personal y evita que el personal este ejecutando varias veces la misma pruebas a lo largo de las iteraciones del proyecto, se puede lograr mucha más productividad ya que las mismas personas pueden lograr más trabajo, con una mejor velocidad, escala y mejora en el rendimiento del personal.

Es conveniente utilizar la automatización de pruebas en un proyecto cuando se tiene mucha repetividad ya que se podrá volver a ejecutar la prueba con un bajo esfuerzo a lo largo de las iteraciones del ciclo de desarrollo, esto permite aumentar el cubrimiento ya que los tester pueden trabajar en las nuevas funcionalidades. 

Así que en resumen, si vamos a tener pruebas repetitivas conviene automatizar, si no se repiten con tanta frecuencia conviene una ejecución manual.


El model based testing o model driven testing:

En este modelo de automatización  no solo implica la ejecución de las pruebas sino que también su diseño, para esto existe el enfoque dirigido por modelos el cual hace énfasis en el “Modelo diseñado para el testing” y el “Modelo del desarrollo”.

Para esta práctica el tester diseña un modelo específico para la creación de las pruebas, como por ejemplo una máquina de estado o cualquier otro modelo que represente como debería comportarse un sistema. El tester deberá basarse en artefactos de desarrollo para poder tomar la información y generar las pruebas,

Un ejemplo podría ser tomar la información de un UML.

Utilizando esta práctica podemos modelar una abstracción de la realidad a través de un modelo de partida. Esto hace que las pruebas tengan un mayor nivel de mantenibilidad y de claridad.


Objetivos en la automatización:

Siempre necesitamos saber cuál es nuestro objetivo dentro de la automatización para saber qué camino debemos tomar, dentro de los objetivos existe un gran nivel de abstracción y una complejidad que posee muchas aristas.

Para eso debemos tener claro cuáles son nuestros objetivos, estos pueden ser:

  • Correr casos de pruebas que hayan quedado sin atención
  • Encontrar errores en la regresión
  • Correr casos de prueba con mayor frecuencia
  • Probar la aplicación en diferentes entornos
  • Consistencia en las pruebas y mitigar las ejecuciones manuales repetitivas
  • Integración continúa para ejecutar de forma nocturna una suite de pruebas
  • Contar con una suite de smoke test
  • Tener un historial de errores

Las pruebas automatizadas no solamente detectan errores que se pueden reproducir de forma manual sino que también detectan errores en el backend de la aplicación, para el caso en el que no solo miremos una interfaz aplicando cierta lógica. Puede detectar problemas de memoria cuando se representan grandes flujos o cuando se realizan pruebas de performance.


Testing basado en riesgos

Cuando ya tenemos encaminado nuestros objetivos utilizamos la técnica llamas “testing basado en riesgos”, esta define qué y cuándo se va a automatizar siguiendo diferentes criterios para determinadas situaciones a lo largo del ciclo de desarrollo.

Algunos factores pueden ser la criticidad de las funcionalidades del negocio, costos que pueden generar el impacto de errores, alguna posibilidad de que existan fallos en el sistema o que sea un tanto delicada la nueva funcionalidad a implementar.

Con un relevamiento de información en detalle se llega a priorizar las pruebas candidatas a automatizar, estas cada cierto tiempo se tiene que revisar ya que pueden llegar a cambiar según la lógica del negocio, para ello es necesario modificar los casos de pruebas.

Es recomendable automatizar no más del 60 % de los flujos en el sistema bajo prueba.


En la práctica

Una vez tengamos los casos de pruebas, asignamos prioridades tanto a los casos de prueba como a las diferentes funcionalidades del sistema. En cuanto al diseño de casos de prueba para ejecutar las automatizaciones,  deben estar divididos o diferenciados en abstractos o conceptuales, y por otro lado, casos de pruebas que utilicen datos de entrada ya que estaremos utilizando estas prácticas para respetar el enfoque data-driven testing. 

El data-driven testing implica tomar datos de una fuente externa, como por ejemplo un Excel o una base de datos, etc. Con el objetivo de poder ir nutriendo esa fuente externa para ejecutar las pruebas con diferentes juegos de datos. A todo esto se agregan las validaciones y por último el oráculo.


Los ambientes de prueba

Las mejores practicas automatizadas se realizan en un ambiente en donde no sufra cambios, o por lo menos que tenga pocos cambios, donde solo pueda acceder la automatización para no volver inestables las pruebas.

Hay que contemplar varios puntos dentro de los ambientes, como por ejemplo :

  • Versionado
  • Artefactos de pruebas 
  • Base de datos

Para el versionado del sistema es necesario tener claro cuales fueron los cambios que se aplicaron para no generar alteraciones en los resultados de las pruebas y que estas fallen, los artefactos de pruebas pueden sufrir modificaciones y por lo tanto debemos plasmarlas en nuestras automatizaciones.

Las bases de datos pueden modificar su esquema, esto puede hacer que los datos en el entorno cambien, en el caso que se tenga un backup de la base de datos, cada cambio de esquema debe ser reflejado en cada uno de esos backup para no generar inconsistencias de datos en las pruebas y que estas fallen.

Los puntos mencionados anteriormente deben estar sincronizados para tener una correcta ejecución, ya que si cualquiera de estos puntos no corresponden puede hacer que las pruebas fallen.

Por lo general existen diferentes tipos de ambientes:

  • El de desarrollo
  • El de verificación de desarrollo
  • El testing dentro del equipo de desarrollo
  • El de pre producción
  • El de producción



Tier Benefits
Pledge $0 or more per null
patrons
Everyone
Recent Posts