Para poder empezar debemos de tener en claro que son los casos de prueba. Los casos de prueba o test case como también se les conocen, son un conjunto de pasos (condiciones y/o variables) y/o resultados esperados con las cuales un analista probará y definirá si un software es parcial o completamente satisfactorio.
Si se cuentan con casos de prueba bien estructurados, estos nos puede redituar a futuro, en donde los ciclos de pruebas puedan ser más fluidos y eficientes, por ello los casos de prueba deben de tener las siguientes características:
- Bien diseñado: El que un caso de prueba esté bien diseñado representa que dependiendo a la funcionalidad que se desea validar, se pueda usar para futuras pruebas (nuevas funcionalidades) y que nos puedan servir para pruebas de regresión.
- Claro: La redacción de los casos de prueba deben de ser de fácil entendimiento, de tal manera que cualquier persona que vaya a hacer uso de un caso lo pueda hacer sin complicaciones.
Al momento de crear los casos de prueba, es muy importante considerar los siguientes puntos:
Conocer y entender los requerimientos del desarrollo.
Para poder desarrollar los casos de prueba, es sumamente importante conocer y entender los requerimientos del desarrollo, por ello se deberá de revisar y analizar la información con los requisitos, especificaciones, diseño funcional, entre otra documentación. Esto se puede revisar en la planeación del proyecto o en los sprint plannings, mientras más conocimiento se tenga sobre lo que se va a desarrollar, será mejor porque en base a el entendimiento que se tenga es como se podrán realizar los casos de prueba para poder abarcar las funcionalidades que se van a desarrollar.
Una actividad que nos puede apoyar en el entendimiento del proyecto, es tener entrevistas con el equipo encargado de ingeniería, ya que ellos podrán visualizar mejor el escenario y aclarar ciertas dudas o profundizar un poco más sobre lo que se va a desarrollar.
¿Qué datos deben incluir los casos de prueba?
No existe una estructura de cómo deberían de estar estructurados los casos de prueba o que datos deben de incluir, ya que dependiendo al tipo de desarrollo que se desee probar o los escenarios será como se personalizaran los casos de prueba, dentro de la misma empresa se pueden tener diferentes tipos de casos de prueba para diferentes proyectos, lo importante es adecuarlos a las necesidades del proyecto y de lo que se desea probar.
Pero para ello mencionaremos los datos que generalmente pueden incluir en los casos de prueba:
- Identificador (ID): Este será el indicador por el cual se puedan diferenciar los casos de prueba, el identificador debe de ser único para cada caso y puede ser numérico o alfanumérico.
- Nombre del caso de prueba: Es un nombre descriptivo del caso de prueba, por el cuál sea fácil de identificar, el nombre del caso de prueba debe representar el nombre del módulo o el área funcional que se va a verificar.
- Descripción: En esta parte se debe de agregar los detalles de lo que se va a probar, por lo que la descripción en grandes rasgos, deberá de proporcionar una visión general del caso de prueba, ya que esto le ayudará a alguien que no tenga mucho contexto, a entender el fin del caso de prueba y como se tiene que llevar a cabo.
- Precondiciones: Es aquella información o elementos necesarios para poder ejecutar los casos de prueba, como por ejemplo:
- Cualquier configuración que se requiera hacer en el entorno.
- Ejecutar en algún orden los casos de prueba.
- Creación de datos (como usuarios, escenarios de prueba, etc.)
- Pasos a seguir: Describe el flujo y los datos que debe de seguir y usar el tester (probador), los pasos deben de ser claros y concretos, para que el tester pueda probar es fundamental que cuente con los datos de la prueba, un ejemplo de pasos a seguir sería:
- Ingresar username válido
- Ingresar password inválido
- Oprimir el botón ingresar
- Resultado esperado: Este punto es sumamente importante, ya que en él se describe lo que se espera deba de hacer la función que se está probando, con el se determinará si la prueba fue satisfactorio o se encontró algún error, por lo que es sumamente importante conocer bien la funcionalidad a probar para poder determinar el resultado esperado.
- Resultado real: En este apartado se describe como su nombre lo dice, el resultado real de la prueba, en el se identificará si fue satisfactorio o en el caso de que no haya sido, se deberá de describir qué fue lo que arrojó la prueba, para en ello poder determinar si es un error o un escenario que no se había contemplado.
- Comentarios: Este punto por ser él último del que hablamos no deja de ser importante, debido a que cuando se finaliza con alguna prueba y se detectó alguna desviación o error, aquí es donde el tester deberá de poner información relevante para que los desarrolladores puedan replicar el error y así corregirlo, algunos puntos que se deben de agregar en este punto son:
- Pasos a seguir para replicar el resultado obtenido
- Datos de prueba
- Flujo que se siguió
- Agregar información de apoyo (capturas de pantalla, videos, etc)
