Respuesta.

La prueba de requisitos es una etapa importante de las pruebas manuales, ya que los errores aquí pueden llevar a costosas fallas en el futuro.

Historia de la pregunta:

En las primeras etapas del desarrollo, los requisitos del producto se documentan (especificaciones, TDR). Su incorrecta o incompleta redacción genera numerosos problemas en la fase de implementación y pruebas.

Problema:

Los requisitos a menudo resultan ser incompletos, ambiguos o contradictorios. Esto conduce a interpretaciones erróneas y a una implementación de baja calidad del producto. El probador debe identificar estos problemas con antelación.

Solución:

Las pruebas manuales de requisitos incluyen:

Auditoría cuidadosa de los requisitos en cuanto a completitud, claridad y coherencia
Elaboración de preguntas aclaratorias para analistas y patrocinadores comerciales
Registro de todos los posibles escenarios de uso (casos positivos y negativos)
Aplicación de técnicas de análisis de requisitos: tablas de consistencia, matrices de trazabilidad, listas de verificación para requisitos

Características clave:

Identificación de contradicciones y "huecos" — detección de discrepancias y situaciones no reflejadas en los requisitos
Comunicación activa con analistas y el equipo — aclaración de detalles, explicación de formulaciones
Formulación de requisitos claros y verificables — los requisitos deben ser unívocos, realizables y medibles

Preguntas capciosas.

¿Qué significa que un "requisito sea verificable"?

Un requisito verificable es aquel sobre el cual se puede afirmar con precisión si se ha cumplido en el producto o no. No se permiten abstracciones, frases generales ni parámetros ambiguos.

¿Se pueden considerar los requisitos de calidad si solo son comprensibles para los autores?

No. Los requisitos de calidad deben ser entendidos unívocamente por todos los miembros del equipo (desarrolladores, probadores, analistas, negocio).

¿Es deber del probador escribir o corregir requisitos?

No, el probador identifica problemas y los comunica a los responsables, pero no debe reescribir los requisitos por su cuenta.

Errores comunes y anti-patrones

Aceptar requisitos sin cuestionar, sin hacer preguntas aclaratorias
Ignorar pequeñas discrepancias y suposiciones
No documentar "huecos" y contradicciones encontradas, esperando que "los desarrolladores se encarguen"

Ejemplo de la vida real

Caso negativo

El probador recibió los requisitos, no verificó su completitud y coherencia, y no prestó atención a formulaciones ambiguas. Como resultado, los desarrolladores interpretaron estos requisitos de manera diferente, aparecieron escenarios no considerados, que solo fueron identificados en el lanzamiento.

Ventajas:

Ahorro de tiempo en la fase de redacción de requisitos

Desventajas:

Muchas correcciones en etapas posteriores
Altos costos de corrección de errores
Insatisfacción del cliente

Caso positivo

En la fase de revisión de los requisitos, el probador elaboró preguntas para el analista de negocios, aclaró puntos controvertidos y ayudó a añadir escenarios negativos. Esto permitió evitar muchas interpretaciones erróneas y reducir significativamente la cantidad de errores en el lanzamiento.