Al fin llegamos a la parte «interesante» de ser QA. ¿Por qué resalto la palabra interesante? Por que la verdad es que yo creo que es muy aburrida, pero de esto dependerá la calidad de nuestro trabajo.
Vamos por parte diría Jack el destripador… Para entender bien que es cada cosa, las voy a definir rapidamente en una oración.
Test Case: Son todos los casos a los cuales vamos a someter el sistema a probar
Test Suite: Conjunto de test cases
Test Plan: Es el conjunto de suites o test cases que se ejecutarán, dependiendo de lo que se quiera probar
Quizas suena un poco engorroso, pero ahora lo voy a explicar con un ejemplo para que se entienda mejor.
Repasando un poco lo que vimos en mi post anterior sobre que es SCRUM, tomaremos el mismo desarrollo como ejemplo y explicaré en que parte entra el QA en el proceso de desarrollo, uniendolo con los conceptos nuevos que vamos a aprender hoy.
Test Cases
Cuando empieza un sprint, los desarrolladores comienzas sus tareas de programación, pero… ¿Qué hacen los QAs mientras esperan algo para testear? Es una pregunta que me han hecho varias personas que se inician en este mundo. Pero la respuesta es sencilla, mientras los Programadores desarrollan, los QA nos ponemos a escribir los test cases.
Si en el Sprint 1 se va a desarrollar el Login y el módulo de Productos, se comienzan a escribir cada cosa que se pueda probar en esos dos módulos.
Existen herramientas para gestionar test cases, como lo es TestLink, es una excelente herramienta y muy completa que permite elaborar suites de test cases y planes de prueba también.
Si bien es una herramienta muy completa, que permite tener un versionado de test cases, asigna automáticamente un ID, se puede describir las precondiciones, los pasos con sus respectivos resultados esperados, etc. Suele ser muy tedioso o poco práctico.
Hoy en día cada vez son más los QAs que me comentan que estan utilizando la escritura de test cases en modo de checklist.
Como se puede ver, en 1 linea, tengo 1 test cases. Este checklist esta hecho en un spreadsheet de Google Drive y lo puedo compartir con el resto de mis compañero QA para repartirnos las tareas y que cada uno escriba o ejecute ciertos test cases.
Comparandolo con TestLink, podemos decir que este método de checklist es más sencillo de hacer, mantener y ejecutar. Pero TestLink permite cosas mucho más complejas, como llevar un control de quien hizo cada test case, cuando se ejecutó y demás.
Para continuar con la explicación de los test cases, tomaremos de referencia el checklist que les compartí. Cada uno es libre de colocar las columnas que vea necesario, yo creo que las fundamentales son las que creé en esa tabla.
Para este caso, esos son los test cases para testear el Login.
ID: Un numero de identificación único para cada test case
Título: De que se trata la prueba que realizaremos (¿Qué se va a probar?)
Pasos: Los pasos a ejecutar para probar dicha funcionalidad (¿Cómo se prueba?)
Resultado Esperado: Lo que esperamos que pase cuando se ejecuten dichos pasos (Lo que debería hacer la app)
Pass/Fail: Si pasó o no el test. Yo incluí también el N/A que quiere decir que NO APLICA
Comentarios QA: Acá dejamos algún comentario si es necesario
¿Como creamos los test cases?
Esta es otra de las preguntas frecuentes que suelen hacerme… Si aún no hay pantallas, ¿cómo sabré que campos o como debe ser la aplicación?
La respuesta es fácil, cuando nosotros nos juntamos con el cliente o el PO, es nuestra misión tomar nota de todos los detalles de la aplicación. Ejemplo: Que campos debe tener el login, si se loguearán con un ID de cliente o con el mail, si habrá link de recuperación de password, si quiere mostrar el logo en el login, etc…
En base a toda esta información recaudada, imaginamos como sería la pantalla y escribimos los test cases pensando en cada cosa que podría probarse en ella.
En el caso del login, podemos probar loguearnos con usuario y contraseña corerctas, usuario correcto y contraseña incorrecta, intentar colocar un SQLi en el login, intentar acceder a la URL del dashboard sin estar logueados, etc.
Y en cada caso agregamos el resultado esperado.
Si ingresamos un usuario y contraseña correcta, ¿Qué debería hacer la aplicación? Redireccionar al dashboard…
Si ingresamos datos incorrectos… ¿Qué debería pasar? La aplicación debe mostrar un mensaje de error
Y así con todo lo que se nos cruce por la cabeza probar.
Además, agregar casos negativos, como por ejemplo el de probar con credenciales inválidas, o insertar letras en un campo en el que solo deberían ir números, etc.
Mientras más test cases escribamos, más escenarios cubriremos.
Quiero aclarar una cosa. Es imposible cubrir el 100% de todos los casos existentes. Quizás creando test cases, podemos cubrir un 80% de los posibles escenarios, es por ello que existen varias estratégias de testing para complementar esto y asegurar una mayor cobertura. (Más adelante, en otro post, veremos más estratégias de testing)
Test Suite
Como bien resumí al principio del post, una test suite no es más que un conjunto de test cases. En la imagen que mostré anteriormente, tenemos la Suite de Test Cases relacionadas al Login.
Seguramente tengamos luego otra Suite con los test cases del formulario de registro, otra para el dashboard, y así con cada módulo que tenga la aplicación.
En caso de que existan test cases que se repitan, yo los suelo poner en una Suite a parte llamada «Genérica» y ahí incluyo los test cases relacionados al header o al footer, que son componentes que se reflejan en todas las páginas del sistema.
Test Plan
Llegamos casi al final del post, acá voy a explicar que es un test plan basado en test cases. Básicamente el test plan es la planificación de como probar la aplicación. Puede incluir distintas estratégias de testing, pero como en este post hemos hablado sobre test cases, lo explicaré en base a ello.
El test plan también sirve como forma de probar integraciones o el conjunto de varios módulos relacionados.
Supongamos que ya se encuentra desarrollado el login, el registro, el módulo de productos y acaban de entregarnos para testear el módulo de VENTAS.
Si bien ejecutamos los test cases relacionados a este módulo, con casos positivos y negativos, también debemos probar la integración con el resto de los módulos. Y acá es acá en donde entra en juego el test plan.
Armamos una planilla por separado, en donde incluiremos los test cases que ejecutaremos para probar esta funcionalidad. Para que quede completo y bien hecho, podemos probar el siguiente flujo:
Registrar un usuario
Loguearse en la aplicación con el usuario creado
Dar de alta un producto
Ir al módulo de ventas y vender ese producto a ese usuario.
Verificar en el módulo de productos que se haya descontado del stock la misma cantidad que vendimos
No es necesario agregar TODOS los test cases de cada cosa. Es decir, TODOS los test cases de registrar un usuario, TODOS los del login, etc… Sino los necesarios para completar el flujo completo, desde que se registra un usuario, hasta que se le vende el producto.
Esto es todo por ahora, espero que en los comentarios cuenten un poco sobre que metodología o forma usan a la hora de crear test cases!
