15 min read
¿Qué son los test cases y cómo elaborarlos?
Un test case o caso de prueba de software es un conjunto de acciones que se planifican y ejecutan para determinar si una aplicación, sistema o sitio web funciona correctamente y de acuerdo a los requerimientos. Para elaborarlos, se recomienda abarcar todos los escenarios de uso posibles y ajustarse a un trabajo metódico y minucioso.
A lo largo de todo el ciclo de desarrollo de software, el equipo de QA (Quality Assurance o control de calidad) desempeña un papel fundamental para **garantizar que los productos digitales salgan al mercado con las funcionalidades esperadas y logrando la satisfacción de las personas usuarias.
Una de las principales tareas del área es la cuidadosa elaboración de casos de prueba, que sirven de guía para evaluar el software en busca de problemas y errores, y facilitan un seguimiento documentado, ordenado y eficiente de los mismos.
En este artículo, exploraramos todo acerca de los test cases: cómo se relacionan con las user stories, cómo escribirlos de manera efectiva y cuáles son las herramientas que pueden utilizarse en este proceso. Además, te dejamos consejos para su diseño, y para mantenerlos actualizados.
En este artículo:
¿Qué es un caso de prueba en testing?
¿Qué es un caso de prueba en testing?
Los casos de prueba son un conjunto de acciones que se ejecutan para determinar si cada una de las funcionalidades de un software cumple con los objetivos de quienes lo idearon y con las expectativas de las personas usuarias.
Cada test case se enfoca en una acción en particular, como por ejemplo, “realizar una búsqueda”, y proporciona instrucciones detalladas sobre cómo llevar a cabo la acción, incluyendo los pasos a seguir (ingresar un término de búsqueda, presionar tecla enter o hacer clic en la lupa, etc.), y el resultado esperado (la presentación de ítems coincidentes con el término de búsqueda).
La intención es determinar si existen errores, defectos o fallas en el software, y en ese caso, informar al área de desarrollo para que lo solucione. Es muy importante que los test cases abarquen todas las acciones posibles y desafíen todos los aspectos del código, desde el rendimiento, hasta la compatibilidad y la seguridad.
De la user story al test case
Durante la fase inicial de un proyecto, el equipo de gestión o PM (Project Management) a partir del diálogo con las personas responsables del producto digital a desarrollar hace un relevamiento del mismo y realiza un desglose del proyecto en épicas.
Una épica engloba un flujo de software completo (login, gestión de perfiles, búsqueda, pago, etc.); y de cada una se desprenden distintas user stories o historias de usuario, que son las acciones que se pueden realizar en ese determinado flujo o sección (iniciar sesión, elegir el idioma del texto, buscar productos de una categoría determinada, seleccionar método de pago, etc).
La user story representa una explicación general de una función de software, desde la perspectiva de quien interactúa con el mismo. Se redacta en una sola oración siguiendo el siguiente formato: “Como [perfil], quiero [objetivo del software], para lograr [resultado]”. Ejemplo: “Como comensal, quiero ver los restaurantes en el mapa para poder elegir el más cercano”.
Si bien se definen al principio, estas descripciones se trabajan de manera colaborativa a lo largo de todo el proceso de desarrollo. Quienes contratan el servicio aportan ideas, y luego el equipo sugiere mejoras en el software que resultan en una evolución continua de las user stories.
Una vez que el producto está avanzado, llega el momento de probar su funcionamiento en pos de garantizar que salga al mercado sin fallas ni errores, y que la interfaz sea intuitiva. Las user stories son las unidades de trabajo más pequeñas de este proceso y requerirán la elaboración de al menos un caso de prueba o test case por cada una, a fin de incluir todos los escenarios de uso posibles.
Por ejemplo, algunos casos de prueba para testear el módulo “inicio de sesión” serían: “utilizar el código recibido por email para crear una contraseña”; “copiar y pegar el código recibido”; “intentar reutilizar el mismo código habiendo transcurrido 24 horas”.
¿Cómo organizar la información para elaborar test cases?
Antes de empezar a redactar casos de prueba, es fundamental comprender los requisitos del producto. Esto implica analizar y organizar la documentación del proyecto, las especificaciones y toda la información que hayan proporcionado las personas involucradas.
El equipo de gestión de proyectos recopila la documentación, la organiza y define tareas para los equipos de desarrollo, diseño y QA en pos de cumplir con el proceso de producción del software. Las mismas quedan plasmadas en tarjetas, cards o tickets en los tableros de trabajo virtuales como Jira o Trello, con el mayor detalle posible, debe quedar toda la información que se necesita para poder completar la “task”. Desde qué gama de colores tiene que tener la pantalla principal o los botones y cuántas secciones se incluirán, hasta el tipo de inicio de sesión (correo electrónico, redes sociales, etc.) o la respuesta esperada de menús desplegables, cuadros de búsqueda o cualquier otro elemento interactivo.
El equipo de QA utiliza esta documentación como punto de partida y como guía para la creación de los test cases, y, en paralelo, visualiza el diseño de la interfaz en Figma (o alguna otra herramienta colaborativa) para ir pantalla por pantalla y saber si hay un botón, si hay una imagen o solo texto, si hay que posicionar el cursor en un lugar determinado, hacer clic o doble clic, etc. El objetivo es contemplar todas y cada una de las posibles interacciones con el software, y garantizar una cobertura exhaustiva de todas las funcionalidades y escenarios.
Se va de lo más general a lo más específico, y como resultado se obtienen muchos tickets más pequeños que los que armó el equipo de PM, donde se detallan paso a paso y de manera clara y precisa, las acciones que se deben realizar para el testeo.
¿Cómo escribir casos de prueba?
Una vez que está organizada la información y que ya sabemos qué es lo que tenemos que testear, llega el momento de escribir. No hay una única manera de hacerlo. Se trata de buscar la metodología de trabajo que resulte más práctica en función de las necesidades del equipo y del proyecto en particular.
En XOOR, el área de QA utiliza tablas que incluyen el nombre del proyecto, la fecha, el nombre de la persona que crea los test cases, y a continuación, distintas columnas con toda la información necesaria:
-
Nombre del módulo a testear: qué parte del software se va a evaluar (por ejemplo, el carrito de compras).
-
Descripción del escenario de prueba o submódulo: cada caso de prueba se enfoca en un "escenario de prueba" particular. Por ejemplo, la adición de artículos al carrito.
-
Descripción del caso de prueba o la acción a ejecutar: qué característica o funcionalidad específica del software se está probando, y qué debe verificarse (hacer clic en el botón “agregar al carrito”, para comprobar que el artículo se agregue correctamente; o visualizar carrito, para chequear que se actualice correctamente el precio*).* Como los test cases son acciones, deben comenzar con un verbo en infinitivo (ingresar, hacer, cliquear, intentar), y es fundamental estipular tanto casos válidos como inválidos para cada requerimiento.
En los casos válidos, se describe una acción que se espera que funcione correctamente, como “cliquear en el botón agregar ítem luego de scrollear hasta el final de la página”.
Por otro lado, los casos inválidos comienzan con el verbo “intentar”, y se utilizan principalmente para verificar que el sistema tenga un correcto manejo de errores. Por ejemplo, si se quiere corroborar que un formulario no permite el envío de un mensaje si no están completos todos los campos, el test case dirá “intentar enviar mensaje con uno de los campos vacíos”.
-
Pre-condiciones: qué requisitos deben cumplirse antes de ejecutar el caso de prueba (por ejemplo, que la persona se loguee bajo el rol de superadmin).*
-
Pasos a seguir: se enumeran una por una y de manera clara las acciones que hay que ejecutar para probar la funcionalidad (por ejemplo, seleccionar un producto y cliquear en añadir al carrito).
-
Resultados esperados: qué resultados se esperan obtener al ejecutar el caso de prueba *(por ejemplo, el precio total en el carrito debe reflejar la suma correcta de los precios de todos los artículos agregados).
-
Resultados obtenidos: qué resultados se obtuvieron realmente al ejecutar el caso de prueba. Siguiendo el ejemplo anterior, si los precios se sumaron correctamente, se registrará “As expected” (de acuerdo a lo esperado). En caso contrario, se escribirá detalladamente el resultado obtenido “el producto no se añadió al carrito, y apareció un mensaje de error diciendo ‘ocurrió un problema, inténtelo nuevamente’. Es importante llevar un registro detallado de los resultados en función de las distintas combinaciones de navegadores y dispositivos que requiera el proyecto.
¿Qué significa ejecutar un caso de prueba?
Al ejecutar un caso de prueba, lo que se está haciendo es comparar los resultados esperados, con los realmente obtenidos. Cualquier diferencia entre ambos será tratada como “bug” (error en el software).
Por ejemplo, al realizar una acción como iniciar sesión con nombre y contraseña, o hacer clic en la imagen de un producto, se genera un resultado específico, que puede ser acceder con éxito a la página web, añadir un artículo al carrito de compras, obtener un mensaje de error, redirigirse a otro sitio, etc.
Cada resultado obtenido se corresponderá con un determinado estado: aprobado, desaprobado, incompleto, bloqueado, y puede haber otros, según el proyecto del que se trate o la forma de trabajo del equipo. Los estados se indican en otra columna, de manera clara, y de acuerdo a un criterio predefinido que puede ser el siguiente:
-
Si el resultado obtenido coincide con el esperado, el caso de prueba se considera “aprobado” (passed), y se indica con color verde.
-
Si no coinciden, esto implica que hay un problema o error en el software para ser corregido. Se marca como “fallado” (failed), se indica en rojo, y se deja asentado en el ticket correspondiente en el tablero del proyecto, para que las áreas de desarrollo puedan corregir la falla.
-
Si el comportamiento que devuelve el software no es totalmente erróneo pero tampoco es exactamente el esperado, el caso de prueba se suele marcar como “incompleto” (incomplete) y se señala en otro color, que puede ser amarillo (por ejemplo, se espera que aparezca mensaje de error al dejar un campo vacío, y aparece cartel de error pero sin texto). En situaciones en las que un caso de prueba fallado bloquea las funciones de los posteriores casos de prueba, se suele marcar como “bloqueado” (blocked), en color gris, y se reporta en otra columna el link del problema (o issue) que causa el bloqueo.
6 consejos para diseñar casos de prueba
A fin de que el ciclo de testeo sea fluido y eficiente, se debe prestar especial atención a la forma de redactar los casos de prueba. Para ayudarte en esta tarea, te aconsejamos:
-
Comprender claramente los requisitos del software antes de comenzar.
Esto ayudará a identificar las funciones y los escenarios de uso relevantes. Por ejemplo, para testear la función de búsqueda en un sitio web de comercio electrónico, asegurate de conocer qué características serán más relevantes para utilizar como filtros, de acuerdo a la clase de productos en venta (si son lavarropas, resultará útil buscar por marca, tipo de carga, tamaño en kilos de ropa, velocidad de centrifugado, etc). -
Definir objetivos claros y concisos para cada caso de prueba.**
Se debe entender con precisión qué se desea verificar en cada caso. Por ejemplo, confirmar que la búsqueda por precio filtre los productos dentro del rango especificado.
-
Escribir de manera completa, en lenguaje simple y comprensible.
Siempre tener presente que no se trabaja en soledad sino en equipo, y por eso debemos buscar la mayor claridad posible para minimizar la incertidumbre. Por ejemplo, en lugar de escribir una descripción vaga como "probar agregar un artículo al carrito", conviene hacerla más detallada y específica: “hacer clic en agregar al carrito y verificar que la cantidad de artículos se haya actualizado correctamente a 1”. -
Incluir casos negativos.
Además de probar los escenarios en los que se espera que el software funcione correctamente (el “camino feliz”), es fundamental incluir casos de prueba negativos, para contemplar situaciones de fallos que pueden ser muy diversas y chequear que los errores se manejen adecuadamente. Por ejemplo, para la funcionalidad de proceso de pago, podría diseñarse un caso de prueba negativo apuntado a verificar qué sucede cuando se intenta abonar con una tarjeta de crédito vencida. -
Priorizar.
No todos los casos de prueba son igualmente críticos. Conviene clasificarlos en relación a la importancia de las funcionalidades que se prueban. Por ejemplo, en una aplicación de compra de bienes o servicios, será de prioridad alta lo que tiene que ver con procesos de pago; de prioridad media, la funcionalidad que permita a las personas usuarias calificar el servicio; y de prioridad baja, lo que tenga que ver con modificar la apariencia o los colores de la interfaz. -
Realizar actualización y mantenimiento.
Es fundamental mantener los test cases actualizados a medida que se avanza en el desarrollo del software con correcciones de errores, mejoras, o agregado de nuevas características, para así tener un informe real del estado de la aplicación. Por ejemplo, si se añade la opción de registro al sistema a través de redes sociales, debería incluirse esta nueva funcionalidad en los casos de prueba.
¿Cómo se realiza el mantenimiento de los casos de prueba?
El mantenimiento de los test cases es una parte crucial en el trabajo del área de QA. Consiste en revisar y actualizar regularmente las pruebas existentes para garantizar que sean efectivas a medida que el software evoluciona y el código se modifica.
Para mantener los test cases actualizados, se realizan distintos tipos de pruebas:
-
Pruebas de integración (integration testing): se enfocan en revisar cómo interactúan entre sí dos o más módulos o componentes del software. Es esencial ejecutar estas pruebas cuando se realizan cambios en ellos, o se añaden nuevas funcionalidades.
-
Pruebas de regresión (regression testing): consisten en volver a correr casos de prueba ya ejecutados, en todos los flujos de una app o feature, a fin de verificar que las nuevas actualizaciones o modificaciones no hayan introducido errores en áreas que antes funcionaban bien.
-
Pruebas de humo (smoke testing): se trata de una revisión rápida del software, a través de algunas acciones exploratorias y aleatorias que permitan detectar cualquier falla inesperada o evidente.
De esta manera, el mantenimiento de casos de prueba garantiza que el software siga funcionando correctamente, incluso luego de incorporar nuevas características. Esto no solo aumenta la confiabilidad y calidad del producto, sino que también favorece la satisfacción de las personas usuarias al evitarles problemas inesperados.
¿Qué herramientas se pueden usar para elaborar casos de prueba?
Existen varias opciones de herramientas que resultan útiles para elaborar y administrar casos de prueba. En XOOR utilizamos Jira, un software de gestión de proyectos desarrollado por Atlassian. También existen otras alternativas, como TestRail, Zephyr, PractiTest, Trello, Asana y muchas más, cada una con sus propias características y ventajas.
La elección de la herramienta más adecuada dependerá de las necesidades específicas de cada proyecto y de cada equipo, y de los recursos económicos con los que cuenten.
Jira ofrece una amplia variedad de funcionalidades que simplifican la creación y el seguimiento de casos de prueba. Permite organizarlos y sistematizarlos, generar y asignar tareas a diferentes profesionales, establecer prioridades y monitorear progresos. Además, la integración de Jira con otras herramientas de desarrollo y testing posibilita una colaboración más estrecha entre estas áreas, lo que agiliza el avance de los proyectos.
El aspecto más interesante de Jira es la posibilidad de generar “tickets”. Un ticket es una unidad de trabajo que representa una tarea específica que requiere atención. Cada uno incluye información detallada sobre la tarea, como su título, descripción, prioridad, estado actual, asignación a una persona del equipo, fecha de vencimiento, y otros datos que puedan ser relevantes.
El área de QA también utiliza herramientas de trabajo colaborativo como Google Drive y plataformas de mensajería profesional y organizacional como Slack, para mantenerse en comunicación con los distintos equipos y partes involucradas, y lograr una fluidez en los intercambios de información y un feedback más completo.
Ahora que ya sabés qué es un test case en programación, si querés entender más sobre la optimización de procesos o el aseguramiento de la calidad en el desarrollo de aplicaciones, te invitamos a leer Qué es QA testing y por qué es tan importante, y a ver en YouTube el workshop “Testing Manual: conceptos básicos, herramientas y metodologías (QA/QC)”. También podés seguirnos en X, Instagram y Linkedin y mantenerte al tanto de novedades y tendencias en tecnología.