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.

Pensamiento crítico en tres palabras: Huh? Really?? So???

Si algo se me ha quedado muy grabado de lo que he leído de James Bach (mi gurú del testing favorito), y que quisiera compartir aquí, es una forma muy peculiar, breve y efectiva para aplicar el pensamiento crítico en el testing del día con día, y que no solamente funciona para los testers sino para cualquier persona que no quiera dejarse engañar. Su método consiste en realizar tres simples preguntas: Huh???  Really???   So??? (algo que traduje burdamente a "¿Qué? ¿En serio? ¿Entonces?")

Supongamos que uno va caminando tranquilo por la calle, rumbo al trabajo, pensando en todos esos bugs que están pidiendo a gritos ser reportados. De repente, entre los arbustos se escuchan unos ruidos extraños y de la nada salta encima un vendedor de herramientas de automatización de pruebas, tratando de vender su producto y proclamando que la automatización es la mejor práctica en el testing, y que además ayuda a ahorrar mucho dinero y esfuerzo. Gracias a James Bach, podría hacerle un alto a esa persona y preguntar:

¿¿Qué??

"Huh?/¿Qué?" me ayuda a recordar que probablemente no comprendo por completo la premisa que se me presenta, y que debo buscar más información respecto a lo que voy a cuestionar hasta entender lo que la otra persona realmente quiso decir. ¿A qué se refiere al decir "automatización de pruebas"? ¿Se refiere al uso de herramientas que ejecutan pruebas unitarias de forma automatizada? ¿Al uso de scripts/addons que facilitan el rellenado de datos de prueba en formularios? ¿Quiere decir la automatización de todos y cada uno de los flujos del sistema de inicio a fin o sólo ciertos módulos seleccionados bajo algún criterio? ¿Sugiere que la automatización por sí sola es la mejor práctica, sin necesidad de otros tipos de pruebas apoyándola? 

¿¿En serio?? 

"Really?/¿En serio?" me ayuda a recordar (una vez que entendí la premisa) que incluso los argumentos mencionados pudieran estar aún en disputa. ¿En serio la automatización es la mejor práctica? ¿Cómo sabe esa persona que realmente es la mejor práctica en el testing? ¿Qué hechos/estudios/experiencias/argumentos tiene para respaldar que es la solución a los problemas del testing y que además representa un ahorro de esfuerzo y dinero? ¿Qué validez tienen los argumentos que lo respaldan?

¿¿Entonces?

"So?/¿Entonces?" me recuerda que a pesar de entender lo que la otra persona quiso decir y de comprender los argumentos que según su criterio dan certeza a su premisa, puede que ni siquiera sea de relevancia en mi contexto o que dichos argumentos no apliquen de igual manera para mi caso. ¿Entonces en qué me beneficia considerar que la automatización es la mejor práctica? ¿Cómo sabe si en mi contexto también pudiera ser la mejor práctica? Tal vez para esa persona sea así debido al tipo de aplicaciones que desarrollan en su empresa. Puede que en mi caso sea mayor el costo de implementarla debido a la cantidad y complejidad de los flujos de mi producto, o que ni siquiera valga la pena el costo de implementación dado que el enfoque del producto requiere más de pruebas exploratorias y de la experiencia del tester, y automatizar flujos no ayude a encontrar los riegos más críticos. También puede ser que de manera general la automatización realmente sea más costosa  en comparación con los beneficios que parece traer con ella.

Con esas tres preguntas me será más fácil aplicar el pensamiento crítico y no dejarme engañar por la primera persona que se me ponga enfrente diciendo que todo saldrá bien.

En lo personal, estas tres preguntas me han ayudado bastante en varias situaciones (no solamente en el trabajo, sino en la vida cotidiana) en las que las cosas parecen ir sospechosamente bien cuando la realidad (o al menos la percepción de la realidad de distintas personas) es otra. Espero que les sea de ayuda este pequeño truco.

Lo que Buda tiene para enseñar a los testers

Hace poco tiempo encontré una presentación de Dawn Haynes donde se habla sobre como el Testing es acerca de “querer aprender y perseguir ese aprendizaje de manera continua” a continuación trataré de explicar un poco de lo que trata la presentación.

En su libro: “El universo en un solo átomo” el Dalai Lama menciona:

“Mi confiada incursión por la ciencia se debe a mi convicción fundamental de que tanto la ciencia como el budismo se proponen comprender la realidad por medio de la investigación crítica: si el análisis científico pudiera demostrar sin lugar a dudas que determinados postulados del budismo son falsos, deberíamos aceptar los hallazgos de la ciencia y abandonar dichos postulados.”

Y es que si lo pensamos un poco, pareciera que se está describiendo el rol que un tester debería tener en una organización, encontrando conjeturas y no conclusiones y estando abierto a que en cualquier momento se podrá encontrar evidencia para abandonar postulados que hasta el momento se toman como hechos.

En su presentación: The Zen of Software Testing, Dawn menciona que Buda invita a no aceptar la validez de sus enseñanzas simplemente sobre la base de respeto a él. Sino que promueve que se pruebe la verdad de sus enseñanzas a través de la evaluación razonada y la experimentación personal.

Es aquí donde podemos encontrar ciertas similitudes que el Budismo y el Dalai Lama tienen para nosotros los testers, buscar la evidencia y evitar caer en suposiciones, en ocasiones es importante cuestionar aquello que pueda parecer obvio con el fin de encontrar nuevos elementos capaces de fortalecer la confianza que tenemos en nuestra visión.

¿Qué opinan?