¿Cómo saber si estas probando bien?

Se me ha enseñado a ver el testing como un proceso infinito, “Las pruebas exhaustivas son imposibles”, “No existe software libre de errores” y “Las pruebas son dependientes del contexto” son 3 de los 7 principios de las pruebas de software diseñados por ISTQB.

Entender el testing como un proceso que lejos de terminarse, es suspendido, puede causar cierta incertidumbre en que tan bien estamos haciéndolo, a continuación listo algunas de las lecciones y los indicadores que me ayudan a saber si estoy probando bien.

Confías en tu equipo de pruebas: Tu equipo tiene la experiencia y el conocimiento adecuado para probar algo, tienen conocimiento tanto del dominio en el que el sistema se desenvuelve, como de aspectos técnicos que los apoyan en las pruebas no funcionales, recordemos: Un tester sólo puede probar lo que conoce.

Tienes muchas preguntas: La curiosidad es el alma del testing, utiliza el pensamiento crítico para cuestionar y evaluar todos los elementos con los que estas trabajando.

Te encuentras a ti mismo en situaciones que no habías pensado antes: De pronto te das cuenta que acabas de encontrar como es que se creó el calendario romano, qué idiomas se hablan en américa latina, como funciona la encriptación asimétrica, el tamaño máximo de un archivo permitido en distintos sistemas operativos entre otras…

Big Bugs: Más que la cantidad de incidencias reportadas, es importante evaluar qué tipo de escenarios estamos reportando, si tus reportes son de alta relevancia en la calidad del producto, es que los esfuerzos se están canalizando de manera adecuada.

Te juzgan de loco: Las pruebas comienzan a tornarse un poco “locas” al incluir escenarios que pudieran sonar poco probables para algunos, tal vez quieras echar un vistazo a la priorización de tus pruebas y ejecutar primero las que sean más probables, pero también son importantes los escenarios “raros”, recordemos que: El pensamiento lateral es el arma fundamental de un tester.

Estás orgulloso de lo que vas a liberar: Las pruebas ayudan a tener una visión amplia de la calidad del producto, los testers deberán estar orgullosos de lo que están liberando, de lo contrario, no se estará agregando confianza al producto o servicio.

Estas aprendiendo: El contexto es una parte fundamental del testing, se debe ver al testing como un proceso multidisciplinario en el que cada sistema traerá consigo el reto de aprender sobre algún tema nuevo.

Te estas divirtiendo: Si no te estás divirtiendo en testing, es que no es para ti, o no lo estás haciendo bien, así que ¡Disfrútalo!

¿Te ha pasado?

Testeando el mundo

Muchos sabemos de unas cuantas características que todo tester debería tener, por ejemplo, curiosidad, creatividad, pensamiento crítico, pensamiento lateral, etc. Y esas características nos ayudan a generar ideas sobre cómo poner a prueba aplicaciones o sistemas, permitiéndonos dar en nuestro trabajo un desempeño, como mínimo, aceptable.

Pero ¿qué pasa cuando se aplican esas características en la vida diaria? ¿En acciones o conversaciones cotidianas? Eso me pasa a mí y puedo ver que le sucede a otros testers. Y no es algo que yo elijo hacer (al menos proactivamente), y yo diría que los demás tampoco.

Muchas personas, sin ser testers, tienen algunas de éstas características, pero el enfoque organizado de estos atributos, que se adquiere al entrenarse en testing, ha hecho que se conviertan en herramientas de la vida diaria.

 Esto da como resultado poder tener una conversación interesante de prácticamente cualquier tema, aun si es algo absurdo. Provoca siempre estar receptivo a inconsistencias o anomalías en cualquier lugar: un supermercado, un libro, una tienda de ropa, hasta los vicios de lenguaje al interactuar con la gente. Hace que te tomes un segundo más para decidir o combinar cosas de una manera diferente a la tradicional y así generas hilos de pensamiento extraños, que no sabes a dónde van a llegar o si serán de utilidad, el único propósito es explorarlos.

Entonces, cuando sucede esto, exactamente ¿qué significa? Puede haber muchas respuestas, pero para mí demuestra que el testing tal vez no es sólo un trabajo, sino una manera de aproximarte a tu entorno. 

Creo que si estás un poco de acuerdo con ésto, tal vez tienes el mejor trabajo en testing que puede haber. ¿Cierto?

Tienes el mejor trabajo en testing que puede haber

El siguiente es un post inspirado en un post de Eric Jacobson, inspirado en un post de Michael Bolton, si, así de poco original soy.

Sin embargo me pareció relevante escribir al respecto ya que se habla del puesto perfecto en testing, y de cómo puede ser tuyo sin que aun te enteres.

Todos sabemos que el objetivo principal de las pruebas de software es el de encontrar fallas o defectos, sin embargo, ¿Será esto lo que realmente motiva a un tester?

En lo personal a mí no me motiva encontrar un defecto, reportarlo, discutirlo y que resulte que no se hará nada al respecto. La motivación viene de otras fuentes como lo es ver que en realidad se está mejorando un sistema, es claro que nunca tendremos un sistema que no falla, pero personalmente encuentro motivación en que al final de cada proyecto, el equipo de testing tiene una lista de formas en las que el sistema fallaba y nos aseguramos que al menos, no lo hace de la misma manera.

Impulsar iniciativas, desafiar el status quo, desenvolverse como profesional en medio del caos, discusiones, debates, procesos pobres, incertidumbre, técnicas de pruebas desconocidas. . . . para mi suena como el área de juegos de un tester.

En poco tiempo he aprendido a disfrutar de mi trabajo, hacer pequeños cambios, mejorar la colaboración entre desarrolladores y testers, todo gracias estos factores antes mencionados que no son otra cosa sino los mejores entrenadores que un tester pueda tener.

Así que hace poco descubrí que tengo el mejor puesto de testing que puede haber y probablemente ustedes también lo tengan.

Espero puedan compartir sus comentarios al respecto.

¿Cómo va el testing en el mundo?

 Desde 2009 Capgemini, Sogeti y HP se han encargado de llevar a cabo un estudio de investigación global sobre las prácticas y tendencias relacionadas a la calidad de software en el mundo, en Septiembre del año pasado publicaron la quinta versión de esta investigación la cual contiene algunos datos que me parecieron interesantes y me gustaría compartir:

·         La inversión del presupuesto de TI en las organizaciones aumento en el área de pruebas de software de un 18% a un 23%, este crecimiento ha sido continuo y se espera que para 2015 sea de aproximadamente 28%.

·         Las pruebas de software centralizadas en un mismo equipo y proceso en las organizaciones subieron de ser un 8% en 2012 a un 26% en 2013.

·         Los ambientes de pruebas crecen, la mayoría de las organizaciones invierte en ambientes permanentes (63%) o temporales (25%) que apoyen a la ejecución de pruebas en un ambiente controlado.  

·         Crecimiento significativo en testing de aplicaciones móviles, principalmente en el área de seguridad, lo que el reporte adjudica a la reciente evolución de aplicaciones móviles ya dedicadas a las transacciones centrales de muchas organizaciones y dejar de lado aplicaciones meramente informativas.

·         La nube está bajando, los servicios y aplicaciones instalados en la nube bajo en porcentaje, personalmente me parece que el “cloud computing” seguirá creciendo aunque en un porcentaje menor ya que considero que acaba de entrar en una fase donde dejo de ser novedad y está siendo utilizado sólo por quienes ya entendieron sus ventajas y desventajas.

·         Testing sigue llegando tarde, y es que cerca de 45% de las empresas encuestadas involucran a testing hasta que la fase de codificación está terminada, lo que ocasiona un decrecimiento  en la influencia que esta fase pueda tener sobre la calidad de la aplicación construida.

Dentro de los países con más participación en el estudio se encuentran: Estados Unidos, Brasil, Holanda, Inglaterra, Suecia y Australia, entre otros con un total de 1500 entrevistas a distintos roles en la organización.

¿Cómo creen que le vaya a México en comparación? El trabajo de testing deberá estar enfocado en romper algunos de los paradigmas con esfuerzos de transformación, los invito a que le den un vistazo a las recomendaciones generales de estas organizaciones y compartan sus comentarios al respecto.

¿Cualquiera puede ser un tester?

Cocinar, como cualquier actividad requiere de habilidades, experiencia y talento. La película Ratatouille relata la historia de cómo una rata se convierte en chef, y una de las frases más recurrentes de la película es: “Cualquiera puede cocinar”.

A continuación una cita de la película donde un conocido crítico opina sobre la idea de una rata cocinando:

 “Una extraordinaria cena de una fuente singular e inesperada, decir solo que la comida y su creador han desafiado mis prejuicios sobre la buena comida, subestimaría la realidad. . . . .Al fin me doy cuenta de lo que quiso decir en realidad. No cualquiera puede convertirse en un gran artista, pero un gran artista puede provenir de cualquier lado”.

Volviendo a la idea, me pregunto: ¿Cualquiera puede ser un tester?

Personalmente, veo al testing como una actividad similar a la cocina, con requisitos de habilidades, experiencia, conocimiento y talento, sin embargo, mientras que las competencias, conocimiento podrán irse adquiriendo mientras una persona se desenvuelve en el rol, creo que existen ciertas habilidades que cualquier persona (sin importar su formación académica) puede tener para convertirse en un gran tester. Habilidades como la curiosidad, creatividad y el pensamiento lateral deberán ser fundamentales para el rol.

De esta manera creo que efectivamente cualquiera puede ser un tester, pero al igual que para cocinar, “No cualquiera puede convertirse en un tester, pero un tester puede provenir de cualquier lado”

¿Tú qué opinas?

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.