Siguenos en:

jueves, 24 de octubre de 2013

El testing solo da problemas

Es cierto, ¿o no? Alguna vez, como tester, ¿te has preguntado o has pensado cuál es tu función en su sentido más básico? Algunos dirían romper software (que personalmente creo que ya está roto desde el principio, en mayor o menor medida), otros dirían que nuestro trabajo es romper ilusiones (demostrar que no funciona, cuando se supondría que sí), acerca del producto que se prueba. ¿No es cierto también que parte de nuestro trabajo es encontrar problemas?, problemas que podrían afectar a nuestros usuarios o hacer que disminuya el valor del producto que se prueba.

Una de las definiciones de la palabra problema, la cual creo encaja muy bien en este contexto, es: Conjunto de hechos o circunstancias que dificultan la consecución de algún fin.Así pues ¿de qué sirven los problemas que encuentra un equipo de pruebas? ¿No son esos problemas revelados con el fin de evitar que los usuarios enfrenten esas dificultades para lograr sus fines? En ese sentido me gusta pensar acerca del tester como una especie de héroe de los usuarios, salvándolos de los problemas, al menos de tantos como nos sea posible.

Pero los problemas o bugs que se revelan en algún proyecto, no solo representan un problema al que un usuario podría enfrentarse. También pueden representar un problema para el desarrollo de dicho proyecto. No siempre es así ya que se puede contemplar una parte del desarrollo del proyecto a corregir bugs. Pero ¿qué pasa cuando los problemas descubiertos en el código sobrepasan el tiempo calculado? Cuando el proyecto se retrasa y las fechas de entrega se acercan. Si consideramos que un proyecto en retraso es un problema, y que los problemas que el equipo de pruebas encuentra están retrasando el proyecto, entonces podemos decir que el testing da problemas al proyecto. Lo interesante de esta situación es que si los bugs o problemas revelados no hubieran sido descubiertos por el equipo de pruebas, seguramente los usuarios los descubrirían, lo cual impactaría negativamente en la reputación y valor de cualquier producto de software y no solo de un producto sino hasta de una organización. Es aquí donde se evalúa qué representa más riesgo, si entregar el producto como está o invertir más tiempo desarrollándolo para mantener al mínimo posible los errores y retrasar más su salida.


Entonces, ¿es malo para un equipo de pruebas solo generar problemas? Más que generar problemas yo lo veo como ayudar a que los problemas se resuelvan. Para solucionar un problema el primer paso es reconocerlo o identificarlo y creo que esa es una de las aportaciones más importantes que un equipo de pruebas hace, al contribuir como parte de un equipo más grande, al desarrollo de un proyecto.