¿Cómo hacemos una tarea de test? En este artículo veremos cómo afrontar una tarea de test como si se tratara de una receta culinaria. Seguiremos la regla mnemotécnica IDPERA: Información, Diseño y Preparación de las pruebas, Test sEssion, Redacción y Actualización.
I) Información
Es clave conocer con precisión qué objeto se pretende testear, pues cualquier sesgo, puede conllevar que el resto de la tarea no tenga sentido. Para reunir y confirmar esta información, es interesante concertar una o varias reuniones con los desarrolladores y managers de producto.
Si tomamos como analogía la cocina, sería como comprender que lo que vamos a cocinar es una paella y no un arroz al horno, y específicamente, una paella de montaña y no una marinera.
¿Cómo lo vamos a testear? Debemos plantearnos cuál será la mejor estrategia y si será conveniente o no automatizar. Reuniremos todos los detalles técnicos necesarios.
Sería como decidir qué ingredientes y utensilios vamos a usar para cocinar nuestro plato.
Aunque cada empresa y cada desarrollador pueden tener sus propios métodos, siempre deberemos tener presente los siete principios del testing, establecidos por el ISTQB (International Software Testing Qualifications Board):
- El testing muestra la existencia de errores, no su ausencia. Reduce la probabilidad de que queden defectos por descubrir en el software, pero, aunque no se encuentre ningún defecto, las pruebas no garantizan una corrección absoluta.
- El testing exhaustivo es imposible. Probar todas las combinaciones de un software es imposible, excepto en productos extremadamente sencillos. Por ese motivo, debemos acotar el alcance, utilizando el análisis de riesgos, las técnicas de test y las prioridades, enfocándonos en ejecutar las verificaciones más significativas y con mayor impacto.
- El testing en fases tempranas del proyecto ahorra tiempo y dinero, al reducir o evitar costosos cambios. Es por ello, que ambos tipos de testeo: el estático y el dinámico, deben comenzar lo antes posible.
- Agrupación de defectos. Normalmente, un pequeño número de módulos contiene la mayoría de los defectos, o es el responsable de la mayor parte de los fallos operacionales. Por este motivo, debemos elaborar nuestra estrategia de pruebas concentrando nuestros esfuerzos justamente en esos módulos más cruciales.
- Precaución con la paradoja de los pesticidas. Las pruebas repetitivas dejan de ser eficaces en la detección de nuevos defectos, al igual que los pesticidas pierden eficacia a lo largo del tiempo. Para evitarlo, deberemos modificar y crear nuevos tests.
- El testing depende del contexto. Las pruebas se deben realizar de forma diferente según el ámbito, teniendo en cuenta el escenario, entorno y caso de uso. Por ejemplo, un software de dispositivos médicos se debe probar de forma diferente a una aplicación de comercio electrónico.
- La ausencia de errores es una falacia. Algunas empresas creen que los probadores, pueden realizar todas las pruebas posibles y encontrar todos los defectos existentes, pero los principios 2 y 1, respectivamente, nos dicen que esto es imposible. En el mundo real “nada es perfecto”, incluyendo el software.
II) Diseño y Preparación de las pruebas
Una vez sabemos qué y cómo lo vamos a testear, pasamos a preparar el entorno y las pruebas en sí. Cubriremos de la forma más eficiente el máximo alcance, priorizando las pruebas sobre casos con mayor riesgo. Hay que tener en cuenta que el “riesgo” se define como la probabilidad de que algo ocurra por el impacto que tendría en caso de que sucediera.
Volviendo a la cocina, podemos pensar que es poco probable que confundamos la sal con veneno, pero si ocurriera, el impacto sería mortal, por lo tanto, nos aseguraremos de que los ingredientes sean los adecuados y no otros.
III) Test sEssion:
En este punto se ejecutan las pruebas en sí.
Empezaremos con un exploratory test, donde el tester configura, opera, observa y evalúa el producto y su comportamiento, investigando de forma crítica el resultado y reportando la información de lo que parecen ser defectos o problemas.
Sería probar la paella directamente e ir viendo si está como esperamos que esté: dureza del arroz, aromas, punto de sal, etc.
Una vez revisado el producto mediante la técnica del exploratory test, si se estima oportuno, pasamos al scripted testing, donde los casos de prueba son diseñados con antelación; incluyendo tanto los pasos a realizar, como los resultados esperados.
Sería como ejecutar una serie de mediciones automatizadas sobre la paella, y compararlas con los valores esperados; por ejemplo: temperatura del caldo en el segundo 225 (se esperan 75º C, con tolerancia +-4º C), peso medio del grano de arroz en el segundo 742 (se esperan 3,25 gramos de media, con tolerancia +-0,27 gramos), etc.
Al encontrar un fallo o un defecto, averiguaremos su alcance, a qué abarca, para así entenderlo y generalizarlo al máximo. Por ejemplo, si encontramos un problema al introducir en un campo los números -1, -3 o -5, investigaremos si el problema acontece solo con esos tres números o con todos los negativos impares o con todos los negativos, etc.
IV) Redacción
Una vez entendido y generalizado el bug, lo redactaremos adecuadamente, empatizando con quién va a leerlo. Explicaremos de manera clara, concisa y precisa todos los detalles del mismo. La estructura debería ser la siguiente:
- Título del fallo o defecto.
- Fecha, versión, release y entorno en el que se ha detectado el error.
- Severidad: Es el análisis técnico del defecto, que indica la gravedad y riesgos que entraña; será el tester quién deberá indicarla (Muy baja, Baja, Media, Alta, Muy Alta –bloqueante-). La prioridad valora la importancia para el negocio que tiene el bug; y establece el orden con el que deberá ser resuelto; será el jefe de proyecto o product owner quién la determine. Normalmente, un defecto de alta severidad es también de alta prioridad, pero no siempre.
- Descripción: Detalle pormenorizado del error encontrado, comparando el resultado obtenido en la prueba con el esperado. Seremos lo más precisos posible; por ejemplo, evitaremos indicar solo: “en la documentación se indica...”, y detallaremos: “en la página X, párrafo Y, de la documentación ubicada en www.documentacion/42.pdf se indica...”, de este modo se podrá contrastar de manera ágil.
- Reproducción: Expondremos detalladamente por pasos, cómo reproducir el mencionado defecto.
- Adjuntos: En este punto adjuntaremos las imágenes, vídeos, logs, etc. que evidencian e ilustran lo expuesto anteriormente.
Nota: Para capturar de imágenes y crear vídeos (GIF), existen multitud de herramientas, tanto de escritorio como complementos del navegador. Por ejemplo, por experiencia personal, son recomendables las herramientas gratuitas: https://getgreenshot.org y https://www.screentogif.com.
V) Actualización
Durante el proceso de test, hemos elaborado y/o reutilizado uno o varios procedimientos de pruebas. Al finalizar, actualizaremos nuestro set de pruebas, así todo lo aprendido nos será útil en un futuro, y no tendremos que rehacer pruebas ya hechas. Como se suele decir: “no deberemos reinventar la rueda”.
Volviendo a la cocina, si observamos que echar el arroz antes de que hierva el agua es una mala idea, pues el arroz queda duro, documentaremos esta prueba, para no tener que volver a diseñarla en un futuro.
Conclusiones
Siempre que vayamos a realizar una tarea de test, deberemos seguir un orden. En primer lugar, nos informaremos detalladamente del objeto a testear; en base a la información recopilada, diseñaremos y prepararemos las pruebas. A continuación, ejecutaremos los tests en sí, para después redactar de forma clara y precisa los defectos encontrados. Finalmente, actualizaremos nuestra documentación y set pruebas, para así poder reutilizar en un futuro todo lo aprendido en esta tarea.
Bon profit!
