En el 2017, cuando aún estaba en Uruguay y formaba parte del equipo organizador de TestingUy (¡hermosas épocas aquellas!) nos propusimos como un gran objetivo traer a algún referente internacional de testing a Uruguay. Y apuntamos bien alto: Michael Bolton, uno de los creadores de Rapid Software Testing.
Luego de varias idas y vueltas para convencerlo (y para poder conseguir sponsors para cubrir el costo) llegamos al acuerdo que iría una semana a Uruguay, donde daría una charla en el evento, participaría de una mesa redonda, y además, daría el curso de Rapid Software Testing (que nos ayudaría a financiar su viaje también).
En este post quiero compartir unas notas que encontré del curso, que también tuve la suerte de poder participar, y que no había llegado a publicar antes. El curso me pareció de los mejores cursos de testing que he podido hacer, pero sobre todo por cómo se ejercita el pensamiento crítico y el mindset de testing.
Antes de leer mis notas, te sugiero leas las notas que tomó Sara, quien también colaboró ese año en la organización del evento y también asistió al curso. Intenté no repetir lo que Sara ya había compartido.
Reflexión sobre falta de documentación
Hizo una dinámica en la que en silencio puso su nombre en un papel.
Lo imitamos para poner nuestros nombres en un papel.
Conclusión: No necesitamos instrucciones específicas para hacer algo. Muchas veces como testers nos encontramos quejándonos de “no hay especificaciones claras”, “falta documentación”.
Ya esto da una pauta de cómo con cosas tan simples logra llamar a la reflexión.
Responsables de la calidad
De Bolton fue que aprendí y adopté la idea de que el testing no es responsable de la calidad, y que el nombre de “QA” (de Quality Assurance) no sería el más indicado (podés leer más en este otro post al respecto y en este otro de por qué no somos los únicos responsables cuando un bug pasa a producción).
Algunos argumentos que resaltó en el curso de por qué no somos responsables de la calidad:
- no manejamos schedule, budget
- no despedimos programadores (sí, suele ser muy tajante con sus comentarios)
- no cambiamos el código fuente
- no decidimos cuándo hacer ship
Our responsability is to shine light on problems on the product, on the quality, to let people make decisions.
Nuestra responsabilidad es de alumbrar hacia los lugares donde hay problemas en el producto, en la calidad, para que la gente tome decisiones.
Lo importante es cuánto coverage podés conseguir en el tiempo que te dan. Cuánto testing en las condiciones de tiempo, presión, información disponible, etc.
Mencionó que no le gustan los ratios, ni los KPI ni las métricas, ya que los managers se basan en esos números que pueden hacer que se desvíen del objetivo. Hace un tiempo escribí un post de cómo las métricas pueden generar comportamientos no deseados si están mal definidas.
Relacionado a esto decía que mucha gente se centra en el número de bugs o número de test cases. En realidad no podemos aprender nada de esos números. Es mejor pasar la lista y el que la recibe si quiere que los cuente.
Test cases
Marcó varias veces que el testing no se limita a test cases. Un test no es algo que escribís, es algo que hacés. A modo de verlo con una analogía, pensando en la música, nos mostró las notas de una canción. Esto no es música, esto es una notación. Todos sabemos que la música es algo que escuchamos.
¿Qué es el testing?
Analizamos algunas definiciones de testing, pero esta en particular es la que resulta interesante: El testing de software es una ciencia social, según lo definió Cem Kaner.
Pensemos que aprendemos a probar socializando en un grupo de testers.
De forma similar, hay una definición interesante de lo que es un programa de computadora: es algo que trata sobre las personas, y además tiene instrucciones para una computadora.
El objetivo es dar valor, hacer algo útil para alguien.
Decisiones sobre qué quiere el cliente
- política: valor para quién
- emocional – no pensamos racionalmente
- pride, fear, desire (relacionado con el concepto de calidad)
En este post hay un análisis más profundo sobre lo que es el testing (y al leerlo verás que está bastante influenciado por la visión de Michael). En mi libro en los primeros capítulos también cuento bastante sobre los conceptos de calidad y testing por si querés repasarlo, nunca está de más.
I don’t break the software, I break the illusions about the software. The software was already broken when I got it.
Yo no “rompo” el software, yo rompo las ilusiones que hay sobre ese software. El software ya estaba roto cuando me lo dieron.
Resultados esperados
Nos dio un ejercicio para hacer, donde básicamente teníamos que probar un sistema que nos proporcionó con el material del curso. Era un programa simple que dibuja un triángulo en base a ingresar las medidas de sus lados.
Nos dijo que la misión era buscar errores y cosas que puedan ser molestas para el usuario.
Al finalizar el ejercicio, alguna de las discusiones que planteó es el tema de la consistencia con expectativas. Esta suele ser una definición de calidad (“que sea consistente con las especificaciones” o “consistente con las expectativas”). Algo que siempre busca Micheal (y es en parte por lo que lo admiro más) es que no acepta las definiciones o estándares o las cosas que todos tomamos como sentadas, sino que las cuestiona y va un paso más allá. Para marcar su punto contó un par de ejemplos:
- Su mujer compró un iPhone, no esperaba lo que compró, pero estaba genial. La percepción de la calidad fue muy alta por más que no estaba acorde a las expectativas.
- Windows Vista: lo que obtuvo fue consistente con sus expectativas, y eso no significa que el producto sea de calidad (sarcasmo a full).
Entonces la pregunta es si tenemos que pensar en el resultado esperado o en el resultado deseado.
Cuando reportamos un bug no se necesita un resultado esperado. Lo que él plantea que deberíamos hacer es documentar la observación y a eso agregarle el criterio o el oráculo que nos hace pensar que hay un problema.
Otra cosa es que mientras estamos testeando, muchas veces no pensamos en cuál es el resultado que estamos esperando. Sin embargo, al ver el resultado, podemos determinar si hay un problema o no. Algunos elementos que nos pueden llevar a determinar que hay un problema:
- Inconsistencia con la forma que sabemos que el mundo funciona (si probamos un sistema de e-banking podemos compararlo con nuestra experiencia usando otros sistemas del estilo)
- Inconsistencia con la forma que el programa fue diseñado.
- Inconsistencia con lo que se anuncia (acá es importante mirar las campañas de marketing y las promesas que se les da a los usuarios).
Entonces, pensando en estos ejemplos, podríamos reportar un bug indicando que hay una inconsistencia en lugar de indicar algo en comparación a un resultado esperado.
¿Qué es un bug?
A bug is something that bugs someone who matters.
Un bug es algo que molesta a alguien que importa.
It’s not a thing, it’s a relationship, between the user and the product.
No es una cosa, es una relación entre el usuario y el producto.
¿Qué es un tester?
A role is a hat, not a tatoo, not a prision
Un rol es un sombrero, no es un tatoo ni una prisión.
El tester debería ser alguien que entiende que las cosas pueden ser diferentes.
En la ciencia y las matemáticas, hay demostraciones que se hacen diciendo “no pude refutar la hipótesis”. Ese es el mindset que es necesario que adopte el tester, ya que así es el testing.
Testability
Cuando hay un problema de usabilidad, puede ser un problema de testability. El usuario afectado soy yo, el tester. O sea, si yo al momento de probar algo (además, muchas veces) veo que hay ciertas cosas que me llevan muchos clics para resolver, o que es difícil de recordar los pasos, etc., al final el problema de facilidad de uso se convierte también en un problema de facilidad de prueba.
Incluso en algunos casos sería interesante desarrollar ciertos atajos o acciones específicas para facilitar la usabilidad para el tester. ¿Por qué es interesante esto? ¿Por qué invertir tiempo del equipo en algo que no está destinado al negocio o al usuario? Para convencernos de esto tenemos que pensar en el riesgo, si es más usable para el tester entonces es más testeable. Si no es testeable los bugs vivirán más tiempo.
Para analizar cómo mejorar la testabilidad podemos centrarnos en buscar confusiones:
- en la documentación
- en la comunicación del equipo
- en las reuniones (quiénes participan, las decisiones que se toman y si se les da seguimiento, etc)
Siempre sirve hacer más preguntas. Pedir que se hagan sistemas más fáciles de probar (porque si no lo pedimos nosotros, nadie más va a pedirlo).
Testing automatizado
Michael Bolton es famoso también por su insistencia en que el testing no puede ser automatizado. Tiene muchos artículos y publicaciones en sus redes sociales al respecto. Si bien yo apuesto a la automatización como algo esencial en el desarrollo de software para poder realizar el testing en forma más eficiente, también me gusta leer su punto de vista como para tener otra mirada, y para analizar la automatización de forma crítica (y así estar con foco en hacerla bien, útil, efectiva para el objetivo del testing).
Cuando estuvo en la mesa redonda en TestingUy hasta incluso cantó un rap que compuso donde cuenta por qué el testing no puede ser automatizado. Por favor, dedicale unos minutos a leerlo porque está muy bueno. Lo compartí acá.
Un comentario gracioso que hizo sobre esto, es que es curioso el nombre del robot que enviaron a Marte. El “explorer” no explora, ni siquiera sabe que está en Marte.
Bug report
Michael también es conocido por usar muchos acrónimos para nombrar heurísticas y así hacerlas más fáciles de recordar. Por ejemplo, una muy útil es la San Francisco DIPOT (que la compartí en este post junto a otras heurísticas útiles).
En este caso nos trajo otra llamada PEOPLE WORK que es útil para considerar al reportar bugs:
- Problem: describir el problema, la observación.
- Example: dar un ejemplo (él sugiere no gastar tiempo en el paso a paso a menos que sea necesario).
- Oracle: ¿cuál es la inconsistencia, cuál es el criterio que tomamos para determinar que hay un problema?
- Polite: ser cuidadoso en cómo se comunica, ni condescendiente, ni con mucho detalle.
- Literate
- Extrapolation
- Work around
Algunas cosas que se suelen hacer al investigar un bug:
- Extrapolation: solo pasa con el ejemplo que encontramos, o pasa en otra cantidad de situaciones.
- Replicate: es importante poder reproducirlo.
- Isolate: intentar aislarlo, identificar cuándo algo sucede y cuándo no.
- Maximize: pensar en lo peor que el bug podría causar.
- Generalize (no recuerdo cuál era la diferencia con la extrapolación).
- Externalize: qué pasaría fuera del test environment.
Reporte de testing
Esta fue de las partes que más me gustó. Al momento de reportar cómo fue nuestro testing, él plantea “trenzar” tres partes de la misma historia (no es necesario que sea en orden):
- Sobre el producto (incluyendo bugs y findings).
- Sobre cómo lo probamos (acá es importante aclarar lo que sí probamos y lo que no, o sea, el coverage)
- Qué tan bueno fue el testing (esto es clave, ya que si alguna parte no la pudimos probar bien, por alguna restricción de tiempo, información o lo que sea, es un riesgo latente que hay que gestionar).
Ejercicio del calendario: testing informal
Probamos un software que imprime un calendario a partir de poner dos fechas límite. Hicimos el ejercicio pensando en valores límite, pero los límites estaban en otro lugar nada que ver a lo que uno podía pensar en base al análisis del problema.
Esto era por la implementación en javascript que la lista comparaba valores no numéricos como si fueran numéricos.
Para hacer testing formal con excelencia primero necesitamos hacer testing informal con excelencia.
Incluso luego agregó que muchas veces no necesitamos testing formal para nada.
Si bien lo vimos en otro ejercicio, algunas otras cosas que vimos relacionado al testing formal e informal:
- Positive testing: cualquier testing que honra todos los requerimientos explícitos.
- Negative testing: se viola al menos un requerimiento explícito.
Testing exploratorio
Otra de las afirmaciones por las cuales Michael Bolton se le conoce, es que todo el testing es exploratorio. Incluso llegó a decir que llamarle “testing exploratorio” es como ir al a verdulería y pedir una “coliflor vegetariana”.
A mí me resulta útil distinguir entre testing exploratorio y testing guionado, para poder saber cuándo estamos basando nuestras pruebas en “test cases” y cuándo lo hacemos con un enfoque exploratorio.
Algo que también mencionó para justificar nuevamente por qué no necesitamos casos de prueba, es que si nosotros dejamos claro cuál es el “por qué” de nuestra prueba y el “qué”, entonces no tenemos necesidad de indicar el “cómo”. O sea, deberíamos concentrarnos en dar la misión de la prueba, qué producto o feature estamos probando, y dejar que el tester decida cómo la va a probar.
If you see something, say something
En alguno de los ejercicios que nos puso, mientras lo explicaba, intencionalmente dio una descripción de manera equivocada. No recuerdo exactamente, pero era algo así como que mientras estaba señalando un grafo que claramente en la pantalla podíamos ver que de “A” se pasaba a “B”, él decía de “B” se pasa a “A”. Creo que muchos nos dimos cuenta del error pero nadie dijo nada.
A la tercera vez de decir lo mismo de manera errada, nos preguntó si nos estábamos dando cuenta que algo estaba mal en lo que él describía. Marcó que a veces la gente que se da cuenta no dice nada “por las dudas”, y cuánto daño puede hacer eso.
Ejercicio de descubrir el patrón
Este ejercicio me gustó tanto que le pedí permiso para usarlo en algunos de mis cursos y talleres (siempre mencionando que él fue el autor y que es un ejercicio del curso de Rapid Software Testing).
El objetivo detrás del ejercicio era mostrar que al hacer una teoría sobre un patrón que estamos buscando, luego el objetivo pasa a ser derribar esa teoría, refutarla. Nunca vamos a poder “garantizar” que encontramos el patrón, porque lo único que podemos hacer es mostrar ejemplos en los cuales se cumple o no se cumple. En este post podrás ver más sobre este ejercicio y cómo lo apliqué en algún taller, y acá está con una explicación más completa.
Luego de ver este ejercicio nos hizo pensar en si es posible seguir los pasos del “testing formal” para resolverlo. O sea, reducir testing a test cases, después buscar la menor cantidad de test cases…
No estamos para hacer testing predecible, sino para descubrir las cosas que no pudimos predecir.
Uso de lenguaje seguro
Una de las cosas que aprendí en mis comienzos como tester, fue el de usar lenguaje seguro. Esto lo aprendí con quién me lideró en mis primeros proyectos, pero claramente todos estábamos influenciados por los mismos referentes. Michael le dedicó un rato a hablar sobre cómo ser cuidadosos con nuestras afirmaciones.
No es lo mismo decir “no hay ninguna interfaz automatizable” que decir “no estoy al tanto de alguna interfaz automatizable”.
También planteó que prestemos atención a palabras como “siempre”, “nunca”, ya que pueden ser generalizaciones que no sean correctas. Es más seguro decir cosas como “no pude encontrar”.
Me interesa tanto el tema que hace unas semanas di una charla interna en Abstracta sobre esto, quizá más adelante la comparta en algún meetup o webinar, o al menos en un post acá.
¿Cuándo terminar las pruebas?
Esta es una de las preguntas difíciles de responder en todo proyecto, pero más que nada si es parte de una decisión mayor que es cuándo estamos listos para liberar la versión del producto a los usuarios.
Testing is never done, it just stops!
El testing nunca está terminado, tan solo se detiene.
Entonces, es importante dejar claro que podríamos seguir haciendo pruebas. También deberíamos marcar qué cosas no se pudieron probar, como para que el stakeholder decida si pausar la salida a producción o si tomar el riesgo de salir sin probarlo.
Modelos para testing
Un model es una representación, una simplificación de la realidad. En el testing todo está basado en modelos. El testing comienza y termina con modelos (desde modelar lo que entendemos del producto, hasta modelos para mostrar los resultados).
The product is not the only thing that is being build, also our idea about the product.
El producto no es la única cosa que está siendo construida, también nuestra idea acerca del producto.
Estuvimos trabajando mucho con mindmaps (para profundizar este tema tan útil, te recomiendo este post sobre mindmaps para testing) e incluso con modelos de datos, formas de representar el conocimiento que nos permitían descubrir información nueva.
Mostró un ejemplo muy interesante con una tabla de datos, a la cual le aplicó un formato condicional y analizó gráfica generada por esos colores. O sea, haciendo un zoom out viendo los datos con el código de colores, se podían observar patrones o características de ese juego de datos, que despertaba la curiosidad en determinadas zonas.
Creo que este tipo de técnicas nos pueden brindar muchas herramientas para probar mejor, justo hace unos días compartí un tweet al respecto, ya que hicimos un curso interno en Abstracta sobre data visualization.
Now I see data visualization design as a very useful skill for testers, not only for generating better reports, but also to try to detect and report anything that can cause misunderstandings in the applications we test
— Federico Toledo (@fltoledo) December 16, 2021
Y otra quote para cerrar esta sección:
Recognize complexity underlying the simplicity of a model.
Reconocer la complejidad debajo de la simplicidad de un modelo.
Estimación
Estuvimos hablando de algo que es muy común en el testing, que es tener que hacer una estimación, responder a la pregunta ¿cuánto tiempo nos va a llevar probar esto? Él dice que su respuesta es que puede probar durante cada minuto que estén dispuesto a darle. Si respondo 3 días y le dicen “eso es mucho”, ok, entonces decime vos cuánto querés que me lleve.
La pregunta debería ser reformulada: ¿Cuándo voy a tener suficiente información para decidir cuándo estamos listos para liberar el producto?
Hay que tener en cuenta que hay distintos niveles de estimaciones, están los obsesivos en un extremo, los razonables en el medio, y los riesgosos en el otro extremo.
Dice game
Uno de los últimos ejercicios del curso fue el “dice game” (en este post podés ver más sobre el juego que lo puse en práctica en algún taller y meetup). Es un juego muy divertido y desafiante, en el post explico el paso a paso para jugarlo.
Set Game
Si bien no fue parte del curso, sé que este juego de cartas es uno de los tantos juegos que a Michael le gustan. De hecho, un día estábamos en un bar y él propuso jugar, ¡y sacó un mazo de cartas del bolsillo!
Playing set game with @michaelbolton in his last dinner with him and the @testingUY team. Result: I won every match 😛 😉
— Federico Toledo (@fltoledo) May 21, 2017
Have a safe trip! pic.twitter.com/pwgfJIMpM2
Es un excelente juego para practicar a aprender patrones (algo tan importante en el testing). Hay un sitio donde se puede jugar online, e incluso hace un tiempo publiqué un desafío de automatización que implicaba automatizar el juego.
Is this a pen riddle – Acertijo ¿es una lapicera?
Otro de los juegos que nos planteó en un bar, fue el acertijo de “¿esto es una lapicera?”. Básicamente es un juego también para desarrollar la atención y la búsqueda de patrones. Hay que descubrir cuál es la situación en la que la pregunta tiene como resultado “sí, es una lapicera” o “no, no lo es”.
Encontré este video de un niño que explica el juego muy claro:
Cerrando
Estoy bastante convencido que se cumplió lo que mencioné en el post Michael Bolton en TestingUy: En lo personal, a mí me encantaría que él se lleve una buena imagen de Uruguay y que se entere de todas las cosas asombrosas que se hacen acá en la industria del software, realmente creo que eso puede generar un impacto en nuestro país y en cómo nos ven o consideran desde afuera.
¿Por qué digo esto? Por lo siguiente:
- Lo sacamos mucho a pasear, comer, recorrer lugares, realmente disfrutamos mucho, nos reímos un montón, creo que logró sumergirse mucho en nuestra cultura.
- Interactuó mucho con la comunidad de testing, no solo en el evento, en el curso, cenas, etc.
- Por último, porque hablando de Uruguay, halagándonos dijo algo así: This is like arriving to the land of the lost testers, iIt’s like “el dorado”.
Si te quedaste con ganas de más Michael Bolton, podés escuchar la entrevista que le hice (en inglés) para mi podcast:
https://abstracta.us/blog/podcast/quality-sense-podcast-michael-bolton/
