De testers y code reviews

Hola, me llamo Mauri y yo también he ignorado las revisiones de código con la excusa de que son “terreno de los desarrolladores”.

¡Pero ya no! Desde que trabajo en Atlassian que me he dado cuenta que, para que la calidad escale con el desarrollo, hay que invertir esfuerzos en la prevención por delante del control o la mitigación, y un buen lugar para prevenir son las revisiones de código, que acostumbran a ocurrir antes de cualquier testing hands-on.

STASH13_PRactivity

Y no quiero oir a nadie diciendo cosas del estilo “pero yo no soy desarrollador” o “es que no sé leer código”, porque no hace falta ser un developercon213añosdeexperiencia para mirarse una revisión de código. Además, leer código es más fácil de lo que aparenta, y las revisiones de código son un buen lugar por donde empezar, ya que los cambios estan asociados a una funcionalidad o bugfix, de tal manera que el código se puede vincular fácilmente a su objetivo.

Listado de 5 cosas al azar que te interesan, como tester, de las revisión de código:

  1. Mayor conocimiento de los sistemas y aplicaciones: como tester más funcional, seguro que ya te conoces todos los recovecos de la interfaz de usuario, ¿por qué no ampliar ese conocimiento con nociones del funcionamiento de la cara interna de las aplicaciones?
  2. Inspiración para futuras fases de pruebas: dependencias inesperadas, secciones complejas, condicionales gigantes, dudas sin resolver expresadas en los comentarios… Este tipo de cosas son pistas invaluables para exprimir las aplicaciones durante la fase de pruebas. Este conocimiento, bien usado y con práctica, hace que el testing sea como jugar al Trivial Pursuit consultando la Wikipedia.
  3. Mejores tests automáticos: el input de un tester en las pruebas automatizadas que vengan con el código (tests unitários, de integración o de lo que sea) puede ser muy útil para que las nuevas funcionalidades nazcan con una cobertura exhaustiva e útil, más allá de los happy paths.
  4. Se cazan bugs también! Que sí, que sí, que se puede! Y no solo bugs, también comentarios confusos, errores de formato, secciones poco claras, tests unitarios que no testean nada… Las revisiones de código son el momento idóneo para corregir este tipo de problemas.
  5. Respeto: también puedes ganarte (más) el respeto de los desarrolladores con tu participación e interés en las revisiones de código, gracias a tus consejos y aportaciones en las mismas. Sabrás que estás por el buen camino cuando tu input sea solicitado en ellas o (todavía mejor) cuando algún desarrollador te pida consejo sobre qué casos de prueba automatizar ¡en la fase de codificación!

Estas son las mías, pero hay muchas más razones por las que, como tester, puede ser interesante participar en las revisiones de código. ¿Cuáles son las tuyas? ¡Cuéntamelo en los comentarios!

Anuncios

expoQA 2012

expoQA 2012

Inesperadamente, he asistido a la edición de este año del expoQA. Digo inesperadamente porque no tenía intención de asistir (las conferencias en general son muy caras, y tal y como está el patio, me parece muy bien que la empresa donde trabajo sea cauta en este aspecto), pero resulta que fui el afortunado ganador del sorteo de una entrada gratis entre los lectores del Testing Planet, revista-diario trimestral muy molona sobre testing, fabricada por la gente del Software Testing Club, y es muy feo rechazar los regalos, no? 😉

Total, que me planté en Madrid la noche del 5 de Junio y el 6 por la mañana, tras algún que otro incidente con el transporte interurbano madrileño (sí, he dicho “interurbano”, porque el venue no era muy accesible que digamos), estaba listo para devorar lo que fuera que se cociera en expoQA, sin saber muy bien cuál era la filosofía de la expo en si misma; es decir, son unas conferencias sobre testing y demás, pero ¿dadas por quién y a qué nivel? Pues a eso iba, a capturarlo.

expoQA

A toro pasado puedo decir…

Nivelazo.

Sin ser muy consciente de ello, me iba a exponer a varias charlas profundamente motivadoras e inspiradoras de #testingheroes como Paul Gerrard, Julian Harty, Graham Thomas, Stefaan Luckermaans, John Reber, Derk-Jan de Grood, Fred Beringer et al. Cada cuál hablando un poco de “su libro”, pero a grandes rasgos, hablando todos de lo mismo: la evolución del perfil profesional del tester, el futuro del rol, la importancia de la automatización para dejar espacio a otros tipos de testing y de mayor valor, como el testing de performance, el testing en dispositivos móviles, el testing de infraestructura…

Eddy Bruin, charlando sobre testing en dispositivos móviles

De las casi 40 ponencias, keynotes y charlas realizadas en los días 6 y 7 de Junio, “mi expoQA” se consolidó en 13 sesiones sobre dos grandes temas: mobile testing (fantásticas charlas por parte de Julian Harty y Eddy Bruin – en la foto -, así como una demo de SilkMobile, herramienta para automatización funcional en móviles de Borland / Micro focus) y filosofía / metodología / background / proceso del testing en general (este tema/s principalmente tocado por los grandes popes anteriormente mencionados).

Me esforzaré por ejecutar un Top 3 de charlas a las que asistí, aunque me quedaba con 7 de las 13, creo…

  1. “The redistribution of testing” – Paul Gerrard: primera sesión, primera keynote, inicio electrizante del expoQA. Que poderío, que ideas tan claras, qué manera de salirse del dogma y ofrecer visión de futuro del tester y su profesión sin sonar fatalista ni pedante. Fantástico.
  2. “Test process improvement : answering the BIG questions” – Graham Thomas: es muy fácil señalar que algo tiene que mejorarse, así como preguntarse cómo mejorarlo, lo que es más complicado es responder a esas preguntas. Muy profesionalmente, este consultor independiente británico ofreció pistas sobre cuándo, quién, cómo… mejorar el proceso de testing. Muy interesante.
  3. Ex Aequo “Mobile testing” – Julian Harty / “Testing in a new world” – Eddy Bruin: empate en mi mente para estas dos en tercer lugar, fantásticas introducciones ambas al mundo de la movilidad y sus entresijos. Justo lo que necesitaba para perder el miedo al desconocido móvil y empezar a tener referencias básicas para empezar con buen pie en este terreno, que hace meses que llama a la puerta de Netquest. Mención especial a Julian Harty, improvisando una sesión magistral (por eso no hay link al programa) ante la ausencia del ponente oficialmente invitado a hablar de este tema. Los grandes se hacen grandes en estos momentos…

Como siempre me pasa en festivales, conferencias y demás, no asistí a las premiadas como mejores charlas de la edición (es algo innato en mi). Fueron las siguientes:

  • “Mutation: a testing technique ready for its transference to industry” – Macario Polo: escogida como la mejor ponencia por parte del comité de la expo, la técnica de la mutación se refiere a introducir errores en el código para comprobar si el testing encuentra esos errores, evaluando la confianza de las suites. Fantástica idea, que puede pegar fuerte en el futuro cercano.
  • “Exploratory Testing Myths” – Luis Fraile: elegida como mejor ponencia por parte de los asistentes, la charla de Luís trató del testing exploratorio desde el punto de vista desmitificador y práctico. Me quedo con mal sabor de boca por no haber asistido a esta, pero no se puede tener todo…

En resumen, gran experiencia, puede ser una práctica recomendable asistir a una gran conferencia sobre testing una vez al año, cargando las pilas y tomando ideas y ejemplo de lo más puntero en el sector, para luego volver a la tierra y aplicar algo de lo que se haya aprendido, ya sea en términos prácticos o filosóficos.

Nos vemos en la próxima edición (o lo intentaremos)!

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.

¿Testing funcional o pruebas de caja negra?

¿Qué mejor que empezar un blog que se llama testing funcional con una definición de qué es el testing funcional propiamente?

Según el “Glosario estándar de términos utilizados en pruebas de software” publicado por el ISQTB y traducido por el SSQTB (obsequio por la asistencia al WinterTest 2011), las pruebas funcionales son pruebas diseñadas tomando como referencia las especificaciones funcionales de un componente o sistema (lo que vamos a testear, el software o una parte de él). Pruebas de funcionalidad, para comprobar si el software cumple las funciones esperadas. Queda claro en esta definición que la estructura interna del software o módulo testeado no se evalúa en estas pruebas, por lo que no afectará a la superación o no de las mismas.

En este mismo glosario, se sugiere como alternativa al concepto anterior el de pruebas de caja negra, pero si acudimos a la definición de este segundo concepto nos encontramos que las pruebas de caja negra…

  • …son ajenas a la estructura interna del objeto de las pruebas (en la estructura interna de los componentes se centran las pruebas de caja blanca)…
  • …pero no albergan solamente pruebas funcionales, sinó que también incluyen pruebas no funcionales.

¿?

Entonces… No son sinónimos? Las pruebas de caja negra incluyen a las de funcionalidad, no? Pero, ¿y qué son las pruebas no funcionales? Un poco reticente, busco si en el glosario hay una definición de este concepto, y me sorprendo encontrándola. Las pruebas no funcionales son pruebas que no se refieren a las funcionalidades (obvio), sinó a atributos transversales a la misma, como la usabilidad, la mantenibilidad, la eficiencia, etc.

Googleo un poco los cuatro conceptos (caja negra, caja blanca, funcional y no-funcional) y todas las fuentes confirman lo anterior, además descubro que se llaman pruebas de “caja negra” porque no se mira en el interior de lo que se prueba y se llaman pruebas de “caja blanca” (o de “caja de cristal”) por todo lo contrario.

Además de confirmar los conceptos del glosario, varias fuentes se refieren a la contraposición entre pruebas de caja negra (aspectos externos, en sentido amplio) y pruebas de caja blanca (aspectos internos), existiendo un fuerte debate sobre qué técnica es mejor. Intuyo que parte de este debate se origina en la histórica confrontación entre desarrolladores y QAs, dado que tradicionalmente las pruebas de caja negra son terreno de los testers, más orientados a la funcionalidad, mientras que las de caja blanca son terreno de los desarrolladores, con mayor capacidad técnica; de todas maneras, estos tópicos sobre “confrontaciones” y “terrenos” me parece que cada vez tienen menor validez en la dinámica y cambiante realidad del sector.

Mi opinión en este debate sobre qué tipo de pruebas es preferible es bastante fácil, ambas son deseables, puesto que nos llevan a la exhaustividad del testing. Las pruebas de caja negra nos aseguran que el software hace bien lo que tiene que hacer (el “qué), mientras que las de caja blanca aseguran que lo hace de un modo adecuado (el “cómo”).

Relación entre caja negra, caja blanca, funcional y no-funcional

Relación entre caja negra, caja blanca, funcional y no-funcional

Aunar estas dos pruebas no es tarea fácil, puesto que se requieren más recursos que si nos decantamos por una única metodología, además de perfiles más versátiles o equipos mayores (desarrolladores orientados a la calidad, QAs con conocimientos de desarrollo). Es fácil de ver que estos dos grupos de pruebas son complementarios y, en caso de combinarlos, tendremos aplicaciones mucho más robustas, pero si hay falta de tiempo o recursos y las aplicaciones tienen usuarios finales no técnicos, parece recomendable centrarse en las pruebas de caja negra, asegurando que lo que se tiene que hacer se haga, aunque no del modo idóneo desde el punto de vista más técnico.

Esto no es siempre así, todo el mundo barre para casa, entonces en cada empresa y según el perfil de los implicados o la metodología de trabajo seguida, el tipo de pruebas que domine un proceso de desarrollo de software será de un tipo o de otro. Si nos preocupa la calidad de lo que entregamos, debemos superar las estrecheces y acercar estas dos posturas, más preocupados por el objetivo final que es la producción de software de calidad total. Por ello es recomendable que los equipos de calidad tengan miembros con formación técnica, y que aquellos que no la tengan adquieran conocimientos básicos de la misma, idealmente guiados por los que sí la tengan. También facilita las cosas que el equipo de desarrollo se imponga como objetivo entregar buen código al equipo de calidad, previa comprobación exhaustiva del mismo, como por ejemplo defiende la escuela del Extreme Programming incluyendo entre sus prácticas el Test Driven Development.

Personalmente, soy más de caja negra y funcional, pero valoro las pruebas más técnicas y me alegro de tener compañeros concienciados y capacitados para hacerlas, además de estar entre mis objetivos el poder contribuir a este testing más técnico. Hay que reconocer que la dualidad de visiones es difícil de gestionar en algunos momentos, además de ser fuente de profundas confusiones y malentendidos, pero tengo esperanzas además de una clara convicción de que juntar las dos miradas es el camino a seguir para entregar aplicaciones excelentes. Y a por eso voy!