Las pruebas se priorizan como las cebollas...

Ahí estás tú, un día cualquiera en tu trabajo de calidad de software, mirando en tu monitor las notas que certifican que acabas de realizar un gran análisis sobre los requerimientos que debes de probar. Te sientes confiado en que harás un buen trabajo de testing y justo antes de empezar, de repente, una pregunta asalta tu mente: ¿Por dónde inicio la ejecución de esta prueba?

Tranquilo, te aseguro que no eres la única persona que le ha pasado. Al momento de elaborar el esquema de pruebas y decidir como las ejecutaremos, muchas ideas entrarán a nuestra mente, especialmente cuando no tenemos mucha experiencia en el software testing.

Nuestra mente es rápida en formular preguntas, que por lo regular se parecen a las siguientes:

• ¿Ejecuto los casos de prueba que toman más tiempo primero?

• ¿Me enfoco en las pruebas funcionales del negocio?

• ¿Ejecuto las más fáciles primero?

• ¿Las ejecuto en el mismo orden que las cree?

Una de las peores cosas que nos puede pasar cuando estamos ejecutando pruebas es que tomemos un mal criterio de priorización, ejecutemos un set de casos de pruebas, levantemos defectos, hagamos que los developer inviertan tiempo corrigiendo estos defectos y luego de todo ese tiempo transcurrido, nos damos cuenta que lo que reportamos no es prioritario y aún no sabemos si la funcionalidad recientemente desarrollada funciona acorde a lo esperado o no.

El científico y novelista alemán Johann Wolfgang von Goethe dijo las siguientes palabras:

"Las cosas que más importan nunca deben estar a merced de las cosas que menos importan".

Acá te propongo una guía lógica "inspirada en shrek" para usarla como buena práctica, a fin de que cada vez que nos encontremos en esta encrucijada, la decisión se haga fácil.

Al reflexionar en cómo plantear una distribución de información que sea fácil de recordar, vino a mi mente aquella famosa y breve conversación que tuvo Shrek con Burro, cuando le explicaba que "los ogros son como las cebollas... porque tienen capas", en ese momento el ogro más querido de la televisión pudo haberse referido a las capas emocionales de su persona, pero en ese instante, también planteó un modelo de referencia interesante, que en mi opinión, podemos aplicar muy bien a las pruebas de software.

Pensemos en lo que implica priorizar...

Es básicamente establecer que va primero y que va después, siguiendo un orden jerárquico de importancia. Una forma de ver esto, es pensar en algo que tenga diferentes capas de profundidad... ¡algo como las cebollas!

Primera capa: Nueva funcionalidad o actualizaciones

La primera capa de este modelo es la más grande y es el punto de partida o la razón principal por la que iniciamos el proceso de prueba.

Acá se encuentran los escenarios y casos de prueba que se encargan de verificar que las nuevas funcionalidades o actualizaciones que han sido aplicadas a nuestro sistema estén acorde a los requerimientos pre establecidos.

Segunda capa: Integración

En esta capa se colocan los casos de prueba que están orientados a probar la relación entre los diferentes módulos del sistema o dado el caso, la integración entre diferentes sistemas que se comunican entre sí para proporcionar un último resultado funcional al usuario final.

Por ejemplo, si se efectuó un cambio en una funcionalidad para realizar una transacción bancaria de una manera distinta, no debemos de dejar de validar el módulo encargado de enviar el correo electrónico al usuario final una vez finalizada la transferencia.

Tercera capa: Regresión

En este apartado son ejecutados los casos de pruebas orientados a validar que las funciones que mostraban un comportamiento correcto dentro del sistema no hayan sido alterada debido a la nueva funcionalidad integrada o a una actualización de una funcionalidad existente.

En esta capa segmentas los casos de prueba a ejecutar según los siguientes criterios: Funcionalidades que tengan mayor impacto en el negocio, funcionalidades más usadas y funcionalidades que han presentado fallos en el pasado, entre otros.

Cuarta Capa: Casos límites (edge cases)

En esta capa se ejecutan los casos de pruebas limites, que son aquellos casos de prueba poco probables pero que de una manera u otra pueden tener un impacto negativo sobre el sistema (aunque no siempre impacto crítico).

Estos casos tienden a ser extremos en relación al uso común del sistema y pueden involucrar combinación de variables anormales tanto para el sistema como para el usuario que lo usa e incluso de ambiente, al tener en cuenta hasta el hardware en el que es ejecutado el sistema.

Las capas y el tiempo

Este esquema de capas nos puede ayudar incluso a tener una referencia de la cantidad de tiempo que debemos dedicarle a cada conjunto de casos de prueba, según en la capa que estemos. Esto claro está, es una sugerencia y no una regla pero, veamos cómo se ven las capas ilustradas como líneas de tiempo imaginarias:

Si tomamos como referencias estas líneas, vemos que la capa de "Nueva funcionalidad o actualizaciones" nos establece que se le debe dedicar más tiempo de pruebas que todas las demás. En contraste, al ver el tamaño de la última capa "Edge cases" nos percatamos que le debemos de dedicar entre 1/4 del tiempo total de pruebas o en síntesis el menor tiempo posible dentro de nuestro ciclo de prueba.

Bonus

Este modelo no solo sirve para ser buena guia de ejecución de pruebas, sino que como ya te habrás dado cuenta, es una buena herramienta de referencia al momento de comenzar a crear tu plan y casos de prueba respectivamente.