Tiempo de lectura: 9 minutos
  • Esto antes funcionaba.
  • ¿Y cuándo se ha roto?
  • Pues justo después de la última vez que funcionó bien, obviamente. No lo sé.

Las cosas se rompen, es un hecho (por supuesto nosotros no las rompemos, se rompen solas, ¿verdad?). Pero lo verdaderamente importante aquí no es saber quién, sino cuándo, ya que si sabes cuándo se ha roto algo, es altamente probable que sepas qué lo ha roto y, por ende, arreglarlo será mucho más fácil (esto no implica arreglarlo en el momento, dependerá del bug encontrado, pero ése es otro tema).

Y de esta parte suelen encargarse los QAs, PERO, aunque no todos los proyectos pueden contar con un equipo de calidad, existe una nueva corriente, QAless, donde un grupo de QAs en la nube se encargan del testing… vale, no. La moda del ~less no ha llegado al mundo del testing aún (hasta donde yo sé). Las buenas noticias son que como desarrolladores podemos hacer algo que, obviamente, no va a sustituir a todo un equipo de QA ni por asomo, pero hará que podamos irnos a la cama por la noche un poquito más tranquilos.

En este post voy a intentar explicar lo mejor posible unas técnicas básicas de Testing Funcional y de Mantenimiento para aplicar a Proyectos Agile cuando no tenemos un equipo de QA, ya que no siempre se puede contar con un equipo específico de calidad. Al menos vamos a intentar probar en los momentos clave y con cabeza, para intentar garantizar la mejor calidad posible de nuestro proyecto, en consecuencia su salud y, en consecuencia, la nuestra.

Primero voy a sentar unas pequeñas bases, conceptos básicos de testing, y luego mi propuesta de adaptación para desarrolladores.

 

Teoría I: When a Smoke is good for your health

Fumadores(1), estáis de enhorabuena, porque un Smoke en testing es bueno para tu salud (y sobre todo para la de tu proyecto). Los no fumadores también podéis echaros un Smoke, ya que éste no es más que un tipo de testing, uno de los muchos que hay. Para situarnos un poco, esta es una (muy) pequeña clasificación de los que voy a explicar:

  • Funcional
    • Unit test
    • Integration test
    • Smoke
    • Sanity
    • Aceptación
  • No funcional
    • Rendimiento, carga y estrés
  • Mantenimiento
    • Regresión

Veamos cada uno de ellos un poco más en detalle…

Niveles Objetivo Alcance Uso
Smoke

Verificar la funcionalidad crítica del Sistema

Health Check general de la aplicación
  • Si el entorno está inestable y queremos hacer alguna prueba rápida para ver si hay algo gordo roto.
  • Antes de ejecutar una prueba larga de Regression, porque si lo básico no funciona, no tiene sentido que empecemos a probar toda la aplicación entera o una parte de la aplicación (pero que sea una prueba larga).
Sanity

Verificar nuevas funcionalidades o corrección de errores en la versión

Health Check especializado en una parte concreta de la aplicación
  • Después de que se lanza una nueva versión, con pocos cambios.
  • A veces se puede usar igual en los mismos casos que los Regression, es decir, hace de Testing de Mantenimiento en vez de Funcional, pero si tenemos poco tiempo o no hay necesidad de cubrir tantas pruebas como en un Regression, entonces podemos hacer un Sanity.
Regression Verificar que el código nuevo no provoca errores inesperados en el existente Health Check preventivo de una parte de la aplicación
  • Cuando hay cambios en los requerimientos, funcionalidades añadidas, corrección de defectos. Por ejemplo, si estamos desarrollando un ticket que creemos que puede romper algo más, es un buen momento para asegurarnos de que toda esa parte de la aplicación que sospechamos que se puede romper, en efecto no se ha roto.
  • Al final del Sprint, analizando los tickets que han entrado en el mismo y a qué han podido afectar, para así intentar cubrir con las pruebas toda esa parte susceptible de haberse roto durante el Sprint.

 

Teoría II: Pirámide de Mike Cohn

Seguro que has visto esta pirámide (o una de sus miles de versiones) alguna vez y si no es así shame on you, voilà, aquí está, la Pirámide de Testing o Pirámide de Mike Cohn(2):

Representación gráfica en forma de pirámide de la forma de cubrir el testing de manera tradicional frente al modo de hacerlo en agile
Pirámide de Testing Tradicional VS Agile

 

Básicamente viene a representar el escenario ideal del testing en un proyecto agile, donde se intenta cubrir la mayor parte del mismo con tests unitarios, en menor medida con tests de aceptación e integración, muy pocos de interfaz de usuario y finalmente algo de Testing Exploratorio que sería la parte manual (ya que todos los escalones anteriores en teoría deben ir automatizados).

Pirámide de Testing que representa las diferentes capas de Testing así como la escala asociada cada capa tanto en tiempo como en costes
Escalas de tiempo y costes asociados a la Pirámide de Testing

También sirve para representar el tiempo/esfuerzo que conlleva cada capa así como el coste de los mismos, siendo estos inversamente proporcionales: es decir, los tests unitarios son rápidos y baratos de hacer y los de interfaz de usuario requieren más tiempo y dinero.

Así que, de entrada, como desarrolladores de un proyecto ágil, lo primero que podemos (y debemos) hacer por la calidad del proyecto es aplicar esta pirámide en la medida de lo posible, para lo cual nos puede ayudar seguir buenas prácticas como TDD, BDD, etc. (pero eso da para otro post, o incluso más de uno).

Eso en cuanto a tests automáticos, pero ¿y esa nubecita con algo de Testing Exploratorio manual?

Testing exploratorio

Aunque el nombre parezca invitarte a probar a lo loco(3), no es realmente la idea. No requiere que escribas casos de prueba y ni mucho menos un Test Plan, pero sí que tiene una serie de características y objetivos, de los que voy a mencionar sólo los que puedo reusar más adelante para la adaptación que buscamos en este post:

  1. Es estructurado, hay que dedicar algo de tiempo a hacer un guión mental de lo que se va a probar (recuerda que probar por probar o probar a lo loco no vale de nada).
  2. Tienen que estar delimitados en el tiempo, lo recomendable suelen ser 90 minutos, ampliables en períodos de 45 minutos.
  3. El tiempo dedicado a esta tarea debe ser exclusivo, es decir, no interrumpir las sesiones.
  4. Hay que reportar los resultados, para poder extraer conclusiones y aprender para un futuro.

 

La adaptación: The moment of truth

Y ahora que ya sabemos qué es un Smoke, un Sanity, un Regression, conocemos la Pirámide de Mike Cohn y el Testing Exploratorio, ¿qué podemos hacer con todo eso como desarrolladores? De entrada, decir que hay que intentar cubrir lo máximo posible con automatización, tal y como nos sugiere nuestro buen amigo el Sr. Cohn, pero aquí he venido a hablar de mi libro testing manual(4).

Ahora sí, esta es mi propuesta: perseguir los objetivos de Smoke, Sanity y Regression aplicando las técnicas del Testing Exploratorio. Una especie de fusión, por así decirlo.

¿Pero cómo exactamente?

No tenemos Test Plans, ni Test Cases, ni nos vamos a poner a escribirlos y ejecutarlos. En su lugar, podemos usar las técnicas del Testing Exploratorio, un poco adaptadas a cada caso, claro está:

  • El guión mental sería aplicable al Exploratory Smoke y al Exploratory Sanity.
  • Delimitados en el tiempo y sesiones ininterrumpidas son características comunes a los tres.
  • Y en cuanto a reportar los resultados, no sería aplicable directamente a ninguno, pero sí algo adaptable al Exploratory Regression.

¿Y tenemos que hacer siempre los tres?

No, ni por asomo. Explico la adaptación de cada uno un poco más en detalle, y ordenados por prioridad:

  • Exploratory Regression: creo que lo más importante sería hacer una pequeña Exploratory Regression al final de cada Sprint. Dedicar por ejemplo 1 o 2 horas a esto, puede ahorrarnos mucho más tiempo en el futuro. Esto puede hacerlo una sola persona o varias, repartiendo diferentes partes de la aplicación entre todos. En este caso con la pequeña excepción de que, aunque no se escriban ni ejecuten Tests Cases, al ser una tarea mayor, sí recomiendo un poco de gestión:
    • Crear un ticket en Jira (o el programa de gestión que se use) donde se repartan las diferentes partes de la aplicación entre las personas que vayan a hacer la regression. Si es sólo una, también te sirve de ayuda para que no se te pase ninguna. Servirá además para imputar el tiempo dedicado a esta tarea.
    • No se trata de probar toda la aplicación, sino de echar un vistazo a lo que se ha hecho en el Sprint y verificar que no se ha roto nada de lo que podría haber sido afectado por dichos cambios.
    • Dedica intervalos de tiempos, sesiones ininterrumpidas. Si tienes poco tiempo, diría que lo más sensato es dedicar por ejemplo sesiones de 30 minutos. Si te da tiempo realizar dos sesiones o tres, bien, si no, una, no pasa nada, pero es importante que durante ese tiempo estés totalmente centrado en el testing y que no te pares a arreglar cada bug que encuentres, mejor lo reportas y sigues con el testing.
  • Exploratory Sanity: está claro que ya probamos que los tickets que desarrollamos funcionan como deberían, ya sean features o bugs (¿verdad que lo probamos?). Pero si dispones de algo de tiempo, deberías dedicarlo a hacer al menos una sesión e ir un poco más allá del Happy Flow. Puedes hacerte un pequeño guión mental de algunas pruebas que puedes hacer en la aplicación para verificar que la feature/bug funciona como debe.
  • Exploratory Smoke: creo que ya los hacemos, pero sin llamarlo de ese modo. Lo haría si acaso, más que como testing previo al Exploratory Regression, como parte del mismo, es decir, empezaría la Exploratory Regression por la parte crítica de la aplicación, por si esta no funciona, parar el testing directamente. No hay que dedicar demasiado para el guión mental, dependerá de la complejidad de la aplicación, pero se trata de checkear rápidamente que lo importante no se ha roto.

 

Conclusiones y/o final thoughts

Insisto y reinsisto una vez más, que lo he dicho unas mil veces y creo que nunca es suficiente, las sesiones de testing no se deben interrumpir, es muy difícil quitarse el sombrero de desarrollador y ponerse el de tester (tanto que no se recomienda en absoluto, pero si es la única opción que tenemos, hagámoslo lo menos mal posible), por eso hay que hacer de uno o de otro, pero de ambos a la vez es un desastre y una pérdida de tiempo. La tentación siempre es arreglar el bug, porque va a ser un momentito, pero no, por muy pequeño que sea, déjalo ahí aparcado que durante ese tiempo no eres desarrollador.

Gif de una mujer probándose diferentes sombreros

Como decía al inicio del post, no puedo insistir lo suficiente en lo importante que es el cuándo encuentras un bug. Si lo haces mientras estás desarrollando lo que lo ha provocado/creado, lo arreglas en un plis plas (o puedes reportarlo detalladamente para cuando tengas tiempo de arreglarlo sepas hacerlo rápida y perfectamente); si lo descubres poco después de haberlo desarrollado, tampoco te lleva mucho recordar, tienes el código fresco. Pero esos bugs que encuentras meses después, que llevan a veces horas localizar la causa raíz para poder arreglarlo, podrían haber sido minutos de haberlo encontrado a tiempo.

Como dice el dicho, “a Smoke a day keeps the distress away”.

Gif de Chandler y Mónica (de la serie Friends) en el que Chandler está fumando y Mónica le riñe
Bad boy Chandler!

Por eso, haciendo un poquito de testing, lo que puedas hacer siempre va a ser mejor que nada (bien hecho y con cabeza (me repito más que el gazpacho, lo sé)) y tu yo del futuro te lo va a agradecer eternamente por los pocos o muchos bugs que puedas encontrar a tiempo.

Mega Post Data

Con este post NO estoy diciendo:

  • Que se pueda, ni muchísimo menos se deba, prescindir de un equipo de QA.
  • Ni que todo lo que hace un QA es probar la aplicación.
  • Ni que yo recomiende que los desarrolladores hagan el trabajo de un QA.

Simplemente hay veces que por lo que sea (no hay dinero, hay dinero y decide invertirse en otra cosa, el cliente no quiere, razón ‘x’ aunque sea irrazonable, whatever) el proyecto no cuenta con equipo de QA, y yo propongo algunas ideas de lo que podemos hacer como desarrolladores por asegurar un poco más la calidad del proyecto.

Ea, ya está, sólo eso, nada más, ya me quedo un poco más tranquila.


(1) Dejad de fumar, for Pete’s sake!

(2) Fun fact: hace poco leí que no queda muy claro que realmente sea de este señor, pero se le atribuye a él.

(3) Para tu tranquilidad, existe un tipo de testing llamado Monkey Testing que consiste justo en eso, en probar a lo loco.

(4) Además de llamar Smoke, Sanity o Regression a los tests manuales, por supuesto también podemos usarlos para los automáticos, y de hecho, es lo recomendable para todas esas capas de la pirámide de Mike Cohn que hemos visto con los diferentes tipos de testing automatizados. Podemos crear sets de tests automáticos para lanzar cuando sea necesario. Un Smoke, un Sanity o una Regresión de una aplicación o una parte de la aplicación puede cubrirse de manera manual, automática o ambas.

Verónica Ojeda

Software Developer @ Gloin - También intento ver todas las series que me recomiendan, leo millones de artículos (desde tecnología, hasta recetas semisanas, pasando por muchos DIY), y por último, pero no menos importante, viajo más de lo que puedo y menos de lo que debo.