La fatiga del tester

Esta semana hemos subido a producción una nueva versión de una de las herramientas propietarias de Netquest que básicamente ha consistido en el rediseño casi total de una de las áreas tratadas por la aplicación. El proceso de testing ha sido largo, duro y difícil, y he sido presa de la fatiga por varios errores de apreciación realizados durante el proceso y que me juro que no voy a cometer nunca más:

  • Incorporación tardía al proyecto: esto es más grave como más tardía es la incorporación (obvio, no? ;-)) y como más grande es el proyecto. Testers y QAs del mundo, hay que encontrar tiempo para asistir a las reuniones de análisis de nuevos requerimientos o funcionalidades (o convocarlas nosotros mismos) para no “perder comba” de lo que sucede. El proceso de testing se pone en marcha más rápido y mejor si no nos coge “en frío” en lo que al contenido se refiere.
  • Desorganización en las pruebas manuales: no tengo los deberes hechos en lo que a organización y documentación de pruebas manuales se refiere. Aunque el rediseño de la herramienta implica casos de uso nuevos y eliminación de viejos (con el consiguiente efecto idéntico en los casos de test), aquellos casos que no han cambiado o que lo han hecho muy poco tienen que estar listos para ser ejecutados y la redacción de casos nuevos tiene que quedar almacenada para futuras situaciones similares. Es importante invertir el ciclo del trabajo y empezar a documentar el testing pensando en el reaprovechamiento futuro de los casos. Una buena herramienta de Test Case Management puede ser de vital importancia en este punto.
  • Falta de automatización en las funcionalidades básicas: de las dos herramientas desarrolladas por la empresa, en esta no tengo nada automatizado. Esto añade gran incertidumbre a aquellas situaciones donde el volumen de trabajo es difícil de asumir, ya que si falta tiempo para validar las nuevas funcionalidades, mejor ni pensar en las existentes. Como más funcionalidades básicas estén aseguradas por pruebas automáticas, más nos podremos concentrar en las funcionalidades nuevas y mejor dormiremos la noche antes de la subida a producción.
La fatiga del tester

Otros factores que contribuyen a que la fatiga haga mella en los testers pueden ser…

  • Procesos largos de pruebas: hacer pruebas es divertido, pero hacerlas bajo presión temporal y durante muchos días seguidos no lo es tanto. Me vuelvo a referir a los puntos anteriores: cuanto antes nos incorporemos al proceso, mejor organizados estemos y tengamos aseguradas las funcionalidades básicas mediante pruebas automáticas, más corta será la fase de (puramente) testing de un proyecto o una funcionalidad nueva.
  • Encontrar muchos errores o muy graves: encontrar errores es buena señal, porque serán corregidos antes de llegar a manos del usuario final; esto siempre es bueno. Lamentablemente, encontrar muchos errores alarga el final del proceso de testing (trasladar los errores a la herramienta de bugtracking correspondiente requiere tiempo e implica que además de validar las funcionalidades, habrá que validar que los errores se han arreglado). Además, encontrar errores graves puede ser algo frustrante, ya que estos errores acostumbran a ser bloqueantes, impidiendo proseguir con la validación de funcionalidades concretas, lo que añade mayor presión temporal a la situación.

Al final, la subida a producción fue bien y se hizo con seguridad, pero el proceso de testing ha requerido de demasiada “fuerza bruta” y las aplicaciones se han hecho demasiado grandes y complejas como para seguir con este planteamiento. Es hora de cambiar de planteamiento y subir el listón para entregar mejores versiones en menos tiempo y con el esfuerzo racionado y concentrado en aquellas áreas que lo requieran, sin perder fuelle en procesos intermedios.

Anuncios

4 comentarios en “La fatiga del tester

  1. Hola Mauri,

    ¡Me ha encantado este post!
    Al tratarse de un área del que tengo un conocimiento 0, no comprendía muy bien los tecnicismos y/o programas y aplicaciones de las que hablabas anteriormente (entiendo también que tu público son más compañeros de viaje y no tanto turistas curiosos como yo XD). Sin embargo, este post, me ha parecido interesante porque bien podría aplicarse a otros departamentos de la empresa.

    Te felicito nuevamente por el blog y por compartir lo que te apasiona de tu trabajo con los demás. Aquí ya tienes a una fan 😉

    Saludos,

    • Rebeca, gracias por tu comentario!

      Me alegro de que te vayas haciendo una idea de lo que es trabajar como QA en un departamento técnico y estoy de acuerdo con la posible aplicación de la fatiga a otros departamentos.

      Por mi parte, gracias por ser una visionaria y prescriptora en todo lo que a comunidades y redes sociales se refiere. Realmente eres de merecido seguimiento.

      Nos vemos!

      Mauri

  2. En la automatizacion de pruebas funcionales se debe analizar si el framework ejecuta los script (Jquery ,ajax, y los script agrupados en los archivos extension *.js ) de nuestra apliccion.
    El framework mas simple; para aplicaciones WEB es el selenium, se ejecuta como u plug-in, o autonoma en la version server. Hay que tener en cuenta que el selenium ,levanta siempre un browser ; para la ejecucion de los test, y esta restigido a aplicaciones web
    Tiene la ventaja de implementar en forma sencilla test regresivo, con instalar el plug-in y ejecutar la aplicacion web se gerenera un archivo. Este achivo desde el browser se ejecuta, repitiendo las macros que ejecutamos (Ejecuncion del test Funcional)
    Pero el plug/in seleniun no se lleva bien , con los scripts Jquery,Ajax; por lo que se recurre al desarrollo en JAVA utilizando el framework de seleniun, deshabilitando la ejecucion del script .La prueba no es completa; porque dejamos de testear las validaciones del lado del cliente que se realizan con Jquery u otra Jscript,el refresco de datos y funcionalidades implementadas con ajax.
    La solucion es divir la automatizacion en dos

    1. Test Funcional > Implemento los casos de pruebas; para evaluar la correcta implementacion de los casos de uso, utilizando Selenium
    2. Test de Scripts >Implemento casos de pruebas; para evaluar el correcto funcionamiento de los script del lado del cliente ,

    Actualmente reemplaze selenium por jwebunit , con groovy .Este cambio amplio la automatizacion , a aplicaciones no web, y moviles

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s