Cuando se está probando una nueva funcionalidad o característica en una aplicación o sitio web, se considera una práctica recomendada tener casos de prueba. Idealmente, el Analista de Pruebas o Tester recibirá los criterios de aceptación para la funcionalidad que se está desarrollando. Cuando QA sabe exactamente qué debe o no debe hacer una funcionalidad, escribir los casos de prueba puede ser bastante fácil. Pero ¿cómo escribir casos de prueba sin requisitos o requerimientos?
Después de todo, en la vida real, en un proceso ágil es probable que no siempre los tenga. Es bastante común encontrar un ticket del tablero del proyecto con una descripción simple y sin una lista real de requisitos. Claro, podrías pedirle a la persona responsable que los agregue. Pero no siempre está claro quién debería ser. (¿El desarrollador? ¿el director o gerente de proyecto? ¿el propietario del producto / Product Owner? ¿Otro?).
En muchos escenarios, la tarea puede pasarse de un lado a otro (el “peloteo” como se dice en Colombia) durante tanto tiempo que retrasa el proceso de prueba por días.
Cómo escribir casos de prueba sin requisitos
Puede resultar abrumador incluso imaginar al QA escribiendo casos de prueba sin requisitos. Pero si se siguen los siguientes consejos, se tendrá un plan sólido para la próxima vez que se sienta intimidado por un escueto ticket que dice estar listo para el control de calidad (QA).
Escribe los casos de prueba en función de la experiencia de usuario ideal
La mayoría de los QAs están bien versados en abogar por una buena experiencia de usuario (User Experience: UX). Incluso si no se sabe exactamente qué pretendía un Product Owner para una funcionalidad determinada, se puede evaluar qué acciones serían las más lógicas para el usuario final.
Haz preguntas al Product Owner o los desarrolladores
No esperes obtener una lista completa de detalles. Pero si hay dudas o se quiere volver a verificar, los Product Owners o desarrolladores pueden ser una gran fuente para aclarar la situación.
Es mejor hacer preguntas específicas, en lugar de dejarlas demasiado abiertas. Esto hará que se obtenga una respuesta más rápidamente y reducirá las posibilidades de tener que hacer preguntas complementarias. Por ejemplo, es posible que te preguntes: «¿Cómo debería funcionar este botón?» En su lugar, podría expresarse como: «Cuando un usuario presiona este botón, ¿a qué sección debe dirigirse?».
Investiga sobre funciones similares en otras aplicaciones / sitios web
El hecho de que una funcionalidad sea nueva para la aplicación o el sitio web que está probando no significa que sea revolucionaria en el espacio tecnológico.
Haz una lluvia de ideas sobre cualquier acción posible que pueda hacer con la funcionalidad
Una buena opción es mirar cada botón seleccionable y cada combinación de opciones posibles. Incluso si es algo que un usuario probablemente no haría, es bueno incluirlo en un caso de prueba. Por ejemplo, «Si el usuario ingresa números en el campo de nombre e intenta guardar, debería aparecer un error».
Pregunta a los desarrolladores qué lógica usaron en el código
Escribir código implica una cantidad de lógica bastante intensa. Si preguntas si se espera que los campos del formulario no se borren después de guardar, se debe preguntar a los desarrolladores si la lógica del desarrollo permite hacerlo, aunque se tenga acceso al código, esta descripción de alto nivel ofrecerá ayuda rápidamente.
Proporciona un resumen de lo que se probará
Cuando se escribe casos de prueba sin requisitos, es posible que se realicen las pruebas con base en suposiciones que pueden ser diferentes a las del Product Owner, tiene sentido mantenerlos informados de que se está probando para que alerten tempranamente si hay desvíos. No sería práctico que el QA se esté deteniendo a cada rato para preguntar cómo debería funcionar cada pequeña cosa (después de todo, ¡proporcionarían requisitos si quisieran tomarse el tiempo para hacer eso!).
Ten una lista estándar de expectativas para cualquier funcionalidad
Existen requisitos que se puede esperar para cualquier funcionalidad. Y no importa si la lista es corta. Por ejemplo, si es una aplicación móvil, esta debería funcionar tanto en iOS como en Android. O si es un sitio web, debería funcionar en los principales navegadores de escritorio y móviles.
También podría incluir estándares de accesibilidad (Accessibility Testing for Websites and Software) comunes. Por ejemplo, «Una persona con visión o audición limitada o nula debería poder utilizar la funcionalidad». (Las pruebas de accesibilidad tienen mas elementos que esto, pero este es un gran comienzo).
O si el software tiene niveles de pago, tal vez solo los usuarios premium deberían poder acceder a las nuevas funciones.
Conclusión
Pedirle al QA que escriba casos de prueba sin requisitos puede generar mucho estrés en él y el equipo, además que pone en riesgo los tiempos del proyecto. Pero si se siguen las pautas anteriores, se puede transitar por la situación con relativa facilidad.
Fuentes
How to Write Test Cases Without Requirements
Imagen por rithwick. pr en Unsplash