Antes de ver como funciona QMETRY, vamos a repasar que es un test case o caso de prueba. Un caso de prueba es un conjunto de condiciones o acciones que se diseñan para verificar si un sistema o componente de software funciona correctamente y cumple con los requisitos y especificaciones establecidos. Estos sirven como documentación, y para ver los alcances de las pruebas (que se va a probar y como)
¿Que es QMETRY?
QMETRY es una herramienta que permite la gestión de estos casos de prueba. Es un plugin de Jira (issue tracker). Así como tenemos QMETRY, existen otros muy conocidos, que más adelante hablaremos de ellos, como lo son XRAY y Zephyr.
Elegí esta herramienta, porque la he visto muy sencilla de utilizar y es muy potente.
Para abrir QMETRY, es necesario comprarlo. No es caro, tiene un plan de 10 licencias que son por proyectos de Jira, después de esto, podrán utilizarla entrando desde el menú superior. Aplicaciones >> QMETRY
¿Cómo crear casos de prueba en QMETRY?
Al ingresar a QMETRY, veremos una pantalla como la siguiente:
Acá es necesario tener en cuenta lo siguiente. QMETRY tiene un menú propio, en donde podremos ver:
– Test Case: Todos los casos de pruebas que escribamos
– Test Cycle: Acá agruparemos los casos de prueba para ejecutarlos
– Test Plan: Los planes de prueba se arman agrupando test cycles
– Test Report: Reporte de la ejecución de los test cycles
Lo único que debemos hacer, es respetar el orden del menú. Es decir, primero creamos los casos de prueba, luego los agrupamos en test cycles, que estos pueden ser estrategias de testing (como regresiones, smoke, etc), por pantallas, o por flujos.
Una vez que tenemos armados nuestros Test Cycles, podremos ejecutar las pruebas. Luego, podremos armar nuestro plan de pruebas, que este contiene 1 o varios test cycles. Podemos armar planes de prueba para probar 1 sola pantalla, un flujo, o un build completo.
Por último, podemos generar reportes de estas ejecuciones para ver los resultados de forma más gráfica.
Lo primero que haremos (como buena práctica) será crear folders o carpetas, para poder ordenar mejor nuestros casos de prueba. No hay una forma correcta de hacerlo, cada uno puede ordenar los casos de prueba como más le guste. En mi caso, me gusta ordenarlos por pantallas. Es decir, creo una carpeta para el Login, otra para el Registro y así con todas las pantallas, y dentro de cada una de ellas, pongo los test cases. Yo lo hago de esta forma, para poderlos encontrar rápidamente.
He visto otros QAs, que los ordenan por historia de usuarios. Es decir, crean una carpeta con el nombre de la historia, y ahí adentro colocan los casos de prueba que van a ejecutarle. Como dije antes, no existe una forma correcta de hacerlo.
Yo prefiero la forma que mencioné anteriormente, ya que después creo test cycles con el nombre de la historia y coloco ahí adentro los test cases que voy a ejecutarle. Me parece mucho más ordenado.
Para crear este folder, simplemente damos click en el botón +Folder y le colocamos un nombre
Una vez hecho esto, podremos crear los casos de prueba dando click en el botón azul +NEW situado en la parte superior derecha. Para que el test case quede dentro de ese folder, debemos clickearlo antes de crear el test case.
Ahora si, es necesario prestarle mucha atención a los campos que debemos completar:
Vamos a repasar punto por punto que es cada cosa. No todos son obligatorios, pero si son muy útiles si contamos con ellos.
1- Summary: Es el título del caso de prueba, es decir, el objetivo de que cosa se va a probar. Siempre pongo entre corchetes la pantalla en la que se sitúa ese caso de prueba y luego el título. A esto lo hago para ver rápidamente de que pantalla es ese caso de prueba sin tener que acudir a leer el folder (Muy útil cuando listamos todos los test cases y no aparecen los folders)
2- Description: Descripción de la prueba. Explicar cual es el objetivo o que es lo que se va a probar (no es obligatorio, pero suele ser útil para explicar un poco mejor el alcance de dicha prueba)
3- Precondition: Acá comentamos que necesito previamente para poder ejecutar esa prueba (No siempre es necesario, solo cuando verdaderamente necesitamos tener algo previo para realizar esta prueba). Por ejemplo. Si vamos a probar un carrito de compras, la precondición sería tener productos cargados en la plataforma, de lo contrario, no podría comprar nada, ni probar el carrito de compras.
4- Priority: Acá especificamos que tan importante es este test case para garantizar el correcto funcionamiento del software. Es muy útil para cuando tenemos poco tiempo de ejecución de las pruebas, simplemente filtramos por los más prioritarios y comenzamos con su ejecución. De esta forma sabremos si al menos lo vital funciona correctamente o no.
5- Assignee: Persona quien ejecutará la prueba. Podemos ser nosotros mismos o no. (No es un campo obligatorio).
6- Reporter: Persona quien creó el caso de prueba. En este caso si es más necesario de completar que el anterior. Esto ayuda a que si un tercero ejecuta la prueba y tiene dudas, sepa a quien preguntarle.
7- Labels: Los labels o etiquetas son muy útiles. Sirven para poder filtrar después los casos de prueba. Podemos colocar el nombre de la pantalla, el ID de la historia, si se va a utilizar en el smoke, en una regresión, etc.
8- Estimated time: No es necesario completarlo, pero si es útil tener una estimación a groso modo de cuanto tiempo llevará ejecutar ese caso de prueba. Esto sirve, para cuando debemos correr varios casos de prueba y queremos tener un tiempo aproximado de cuanto tiempo nos llevará finalizar la ejecución.
Una vez completado todo esto, pasamos a la pestaña de «Steps» para escribir los pasos de este test case.
No hay mucho que explicar acá, simplemente colocamos los pasos uno debajo del otro. El campo de test data, es por si hay que añadir algún dato de prueba, como por ejemplo: credenciales, querys, etc. En caso de que no necesitemos nada, simplemente los dejamos vacíos. Por último, completamos el resultado esperado.
He visto que muchos le ponen resultado esperado a cada paso del caso de prueba. No esta mal, pero no es necesario. Digo que no es necesario, porque lo que debemos verificar en realidad, es lo que indica el objetivo del test, que por lo general esta en el último paso. (podemos tener más de un resultado esperado por caso de prueba, pero no es necesario que todos los pasos lo tengan, solo los que verifican algo relacionado al objetivo del test)
Parece mucho, pero en realidad es menos de lo que se imaginan. Tengan en cuenta que yo he explicado todo paso a paso, pero simplemente son un par de clicks. También se pueden clonar los casos de prueba, por lo que si son similares, simplemente los clonamos y editamos lo que haga falta.
Una vez completado los pasos y resultado esperado, clickeamos el botón CREATE, ya ya tendremos el test case hecho.
En el caso de la imagen anterior, hay 2 casos de prueba creados.
Otra cosa que quiero aclarar acá (que está mal en la imagen) es que los test cases deberían tener como título: «Verificar que…». En el caso anterior, sería: «Verificar que el usuario pueda loguearse al sistema utilizando credenciales válidas».
Lo que resta ahora, es seguir creando más test cases para dejar completa la suite del login, y luego seguir por la siguiente…
Test Cycles
Como expliqué anteriormente, un test cycle sirve para agrupar test cases, para luego ejecutarlos. A estos ciclos de prueba podemos agruparlos por estrategia de testing, módulos del sistema, historia de usuario, etc. Para este ejemplo, Voy a crear uno para correr una regresión.
Para ello, presionamos el botón azul +NEW y colocamos un título y descripción. Si quieren pueden completar el resto de los campos, pero eso ya queda a criterio de ustedes. Si ven que son muchos casos de prueba, pueden colocar un start date (cuando comenzarían) y un end date (cuando creen que terminarían de ejecutarlos a todos)
Una vez que tenemos completo todo esto, vamos a la pestaña de Test Case, para poder seleccionar los casos de prueba que entrarán en esta ejecución. Acá clickeamos el botón que se llama «Link Test Case(s)», para agregar los casos de prueba que creamos anteriormente
Vamos seleccionando los test cases, y los vamos agregando a este ciclo de pruebas. Si vamos a agregar casos de pruebas de distintos Folders, clickeamos en Link, y cuando y sino, Link & Close para linekar los seleccionados y cerrar la pantalla.
Una vez que finalicemos, damos click en «CREATE» y tendremos listo nuestro ciclo de prueba para ejecutarlo
Ahora simplemente damos click en el ícono de PLAY para comenzar la ejecución
Una vez presionado ese PLAY, veremos todos los casos de prueba de ese test cycle. Acá el procedimiento es muy sencillo, simplemente debemos ir uno por uno, ejecutando los pasos en el sistema y clickeando el color VERDE si funciona como se espera o ROJO, si el caso de prueba falla.
Algo que se presta para confusión, es que hay colores verdes y rojos tanto en el listado de la izquierda, como en el de la derecha. Esto es porque en la izquierda podemos poner test case por test case si pasa o falla, y del lado derecho, podemos especificar que paso de un test case fue el que falló (Como para hacerlo más atómico). Pueden ejecutarlos como quieran.
También, en caso de que los ejecuten paso por paso, pueden adjuntarles evidencia a los pasos, así como también reportar un bug desde ahí mismo en caso de que uno falle. Nuevamente, como dije antes, esto queda a criterio de cada uno de ustedes.
Si volvemos a la pantalla de TEST CYCLE, podremos ver el avance de la ejecución:
Test Plan
Quizás un poco confuso ver el nombre de test plan acá, muchos se imaginarán o dirán que un test plan es otra cosa, y de hecho para mi también es otra cosa, pero a groso modo, esto también es un test plan. QMETRY le llama test plan, al conjunto de test cycles. Arma un plan de pruebas basándose en los test cases que vamos a ejecutar. Bajo mi criterio es un poco pobre, pero a fines prácticos sirve para presentar algo rápido y visible al equipo de trabajo.
Muy similar a lo que hicimos con el Test Cycle, acá vamos a clickear el botón «+ NEW«, le colocamos un nombre, descripción y todo el detalle que deseemos agregarle.
Luego nos vamos a la pestaña de Test Cycle, y acá seleccionamos el/los Test Cycle que va a incluir este test plan
Un pequeño detalle a aclarar, que también me han preguntado con frecuencia, y es cuantos test cycles pueden incluir. Yo lo que suelo hacer es lo siguiente.
1- Creo todos los casos de prueba (por pantalla, como vimos en la primer parte, repartidos en carpetas)
2- Creo Test Cycles, que estos pueden ser por historia de usuario. Entonces cada historia, tendrá una cierta cantidad de casos de prueba que serán ejecutados. Otra variante, es que pueden separar los test cycles por flujos (un recorrido en la aplicación. Ejemplo: Si tenemos una tienda, incluiría los casos de prueba para crear un producto, luego para agregarlos al carrito de compras, pagarlo, verificar que llegó el mail de confirmación, etc), y sino pueden crear Test Cycles por estrategias de testing, como por ejemplo el smoke o regresión, en donde van a incluir algunos casos de prueba de cada funcionalidad. Esto va a depender mucho de como sea el proyecto y como lo quieran probar, o que necesiten probar.
3- Por último, creo un plan de pruebas. por lo general suelo hacerlo por sprint o por build. Es decir, si va a salir la a producción la versión 1. Creo test cycles con test cases que cubran todas las pantallas que saldrán a producción, y luego meto a esos test cycles dentro del test plan.
Test Report
Llegamos al final! Una vez que ya tenemos los test cases hechos, los test cycles ejecutados y armamos nuestro test plan con esos ciclos de prueba, estaríamos en condiciones de generar el reporte.
Para ello nos dirigimos a la pestaña de test report, y simplemente indicamos que cosa queremos graficar. En este caso, coloqué para que muestre un resumen de como viene la ejecución de los casos de prueba.
Esto es todo por ahora. QMETRY tiene mucho más para ofrecer, como por ejemplo, permite versionar los casos de prueba. De esta forma, cuando alguna pantalla que ya testeamos sufra alguna modificación, no debemos crear un nuevo caso de prueba, sino que creamos una versión de uno ya existente.
Otra cosa buena que tiene, es que posee un módulo para hacer test exploratorios. Este instala un plugin en Chrome, que va capturando los clicks que hagamos en el sistema que estamos probando, y con esto arma documentación sobre ese test exploratorio.
Por otro lado, también posee integraciones con sistemas de CI/CD para correr pruebas automatizadas. De esta forma, se vinculan nuestros casos de pruebas manuales con los automatizados, y una vez que se corre la ejecución automatizada, se cambia el resultado de la ejecución en los casos de prueba de nuestro QMETRY.
Espero que les haya gustado el post y que les sirva! Para ver más posts sobre QA, revisá la categoría de testing de este mismo blog. O visitá la sección de QA del foro de Underc0de
ANTRAX
