Para probar software necesitamos saber qué comportamiento se espera. Si no conocemos los requisitos, los criterios de aceptación o los casos de uso, será difícil decidir si el sistema funciona correctamente.
Los requisitos describen qué debe hacer el sistema o qué condiciones debe cumplir. Los criterios de aceptación ayudan a decidir cuándo una funcionalidad puede considerarse terminada. Los casos de uso describen interacciones entre un actor y el sistema para lograr un objetivo.
En este tema veremos cómo estos elementos ayudan al testing y cómo se relacionan con el diseño de casos de prueba.
Un requisito es una necesidad, condición o capacidad que el sistema debe cumplir. Puede describir una funcionalidad, una regla de negocio, una restricción técnica o un atributo de calidad.
Ejemplos de requisitos:
Un requisito sirve como punto de partida para diseñar pruebas. Si está mal escrito, incompleto o ambiguo, las pruebas también pueden quedar incompletas o confusas.
Los requisitos suelen clasificarse en funcionales y no funcionales.
| Tipo | Qué describe | Ejemplo |
|---|---|---|
| Funcional | Qué debe hacer el sistema. | El usuario debe poder recuperar su contraseña mediante un enlace enviado por correo. |
| No funcional | Cómo debe comportarse el sistema o qué atributo de calidad debe cumplir. | El enlace de recuperación debe generarse en menos de dos segundos. |
Ambos tipos son importantes para el testing. Una funcionalidad puede hacer lo correcto, pero ser demasiado lenta, insegura o difícil de usar. En ese caso, cumple parte de lo esperado, pero no alcanza la calidad necesaria.
Un buen requisito debe ser fácil de entender y de verificar. Algunas características deseables son:
Un requisito ambiguo podría ser:
El problema es que "rápidamente" puede significar cosas diferentes para distintas personas. Para un usuario podría ser un segundo; para otra persona, cinco segundos. Como no hay un valor concreto, la prueba queda abierta a interpretaciones.
Una versión más verificable sería:
Ahora podemos diseñar una prueba con datos, condiciones y resultado esperado claro.
Un criterio de aceptación es una condición que debe cumplirse para considerar que una funcionalidad fue implementada correctamente desde la perspectiva del negocio, del usuario o del equipo.
Los criterios de aceptación responden preguntas como:
Para testing, los criterios de aceptación son muy valiosos porque permiten convertir expectativas en pruebas concretas.
Una forma habitual de escribir criterios de aceptación es el formato Dado-Cuando-Entonces. Este formato ayuda a expresar contexto, acción y resultado esperado.
Ejemplo:
Este criterio puede transformarse fácilmente en un caso de prueba porque define precondición, acción y resultado esperado.
No debemos escribir criterios solo para el camino exitoso. También son importantes los casos alternativos, errores y límites.
Ejemplos para inicio de sesión:
Estos criterios ayudan a probar condiciones que podrían quedar olvidadas si solo pensamos en el uso ideal.
En metodologías ágiles, los requisitos suelen expresarse como historias de usuario. Una historia de usuario describe una necesidad desde la perspectiva de quien usará o se beneficiará de la funcionalidad.
Un formato común es:
Ejemplo:
La historia de usuario no reemplaza los criterios de aceptación. La historia describe la necesidad; los criterios aclaran cuándo se considera satisfecha.
Un caso de uso describe una interacción entre un actor y el sistema para alcanzar un objetivo. El actor puede ser una persona, otro sistema o un proceso externo.
Un caso de uso suele incluir:
Los casos de uso son especialmente útiles para entender procesos completos y diseñar pruebas de flujos de negocio.
| Nombre | Recuperar contraseña |
|---|---|
| Actor principal | Usuario registrado |
| Objetivo | Obtener un enlace para crear una nueva contraseña. |
| Precondiciones | El usuario tiene una cuenta registrada con correo válido. |
| Flujo principal | El usuario solicita recuperación, ingresa su correo, recibe un enlace, abre el enlace, define una nueva contraseña y confirma el cambio. |
| Flujos alternativos | Correo no registrado, enlace vencido, contraseña inválida, enlace ya utilizado. |
| Postcondición | La contraseña queda actualizada y el enlace anterior no puede reutilizarse. |
A partir de este caso de uso podemos diseñar varios casos de prueba: uno exitoso, uno con correo inexistente, uno con enlace vencido, uno con contraseña débil y otros escenarios relevantes.
Los requisitos y criterios de aceptación son entradas importantes para diseñar casos de prueba. Un caso de prueba toma una condición específica y la convierte en pasos, datos y resultado esperado.
| Elemento | Pregunta que responde | Ejemplo |
|---|---|---|
| Requisito | ¿Qué debe hacer el sistema? | El usuario debe poder recuperar su contraseña. |
| Criterio de aceptación | ¿Cuándo se considera correcto? | Si el correo existe, el sistema debe enviar un enlace válido por 30 minutos. |
| Caso de prueba | ¿Cómo lo verificamos concretamente? | Ingresar un correo registrado, solicitar recuperación y comprobar que llega un enlace válido. |
La trazabilidad permite relacionar requisitos, criterios, casos de prueba y defectos. Es útil para saber qué se probó, qué falta probar y qué impacto tiene un cambio.
Ejemplo:
Con trazabilidad, si cambia el requisito R-15, podemos identificar rápidamente qué criterios y pruebas deben actualizarse.
Cuando un tester revisa un requisito, puede hacer preguntas como:
Estas preguntas no son obstáculos. Son una forma de mejorar la claridad y prevenir defectos antes de desarrollar.
Al trabajar con requisitos y criterios de aceptación, algunos errores frecuentes son:
Estos errores aumentan el riesgo de construir y probar algo distinto de lo que realmente se necesita.
Para mejorar la relación entre requisitos y testing conviene:
Un requisito claro reduce discusiones, mejora el diseño de pruebas y facilita la aceptación de una funcionalidad.
Los requisitos, criterios de aceptación y casos de uso son la base para diseñar pruebas efectivas. Permiten entender qué debe hacer el sistema, bajo qué condiciones y con qué resultado esperado.
Un tester aporta valor cuando ayuda a transformar ideas generales en comportamientos verificables. Las preguntas correctas al inicio pueden evitar defectos costosos más adelante.
En el próximo tema estudiaremos los niveles de prueba: unitarias, integración, sistema y aceptación, para comprender en qué capas se puede evaluar el software.