Respuesta

Contexto de la pregunta:

A medida que crece la complejidad del software, se ha observado que algunos errores solo se encuentran fuera de los casos de prueba o especificaciones; a menudo, estos errores son los más críticos para los usuarios reales. Para encontrar tales defectos, los probadores utilizan técnicas especiales, combinando pruebas estándar con su propia experiencia.

Problema:

Los errores ocultos relacionados con la interacción de componentes, el manejo inapropiado de situaciones no evidentes o la falta de requisitos son los más difíciles de detectar y registrar. A menudo, los probadores no están seguros de si deben documentar el problema encontrado si "no está descrito en los requisitos".

Solución:

Se utilizan métodos de pruebas exploratorias, pruebas en pareja y experiencia en productos similares. Siempre documente dicho error con el mayor detalle posible: pasos, observaciones, por qué considera que es un defecto, enlaces a requisitos relacionados o lógica aceptada.

Características clave:

Necesidad de iniciativa y pensamiento crítico.
Es importante argumentar por qué se trata de un defecto.
En algunos casos, es necesario participar en discusiones con analistas/PO.

Preguntas trampa.

¿Se pueden ignorar o no documentar errores que no están descritos en los requisitos?

No, siempre informe, incluso si no hay un enlace exacto al requisito, de lo contrario, los problemas críticos llegarán al cliente.

¿Es una incomodidad para el usuario un error o una mejora (feature request)?

Si el comportamiento es claramente ilógico, causa confusión o riesgos, regístrelo como un error; de lo contrario, como una mejora.

¿Debería un probador consultar con el equipo sobre cada error no evidente?

Se recomienda discutir previamente el caso controvertido con un analista o desarrollador para evitar tickets innecesarios.

Errores comunes y anti-patrones

Ignorar defectos evidentes para los usuarios que no están descritos en los requisitos.
Documentación débil/incompleta de errores ocultos.
Falta de argumentación para el informe de error.

Ejemplo de la vida real

Caso negativo

Un probador notó que al abrir simultáneamente dos ventanas, el sistema se bloqueaba, pero no registró el error, ya que dicho escenario no estaba descrito en los requisitos ni en los casos de prueba.

Ventajas:

No agregó un error "innecesario", liberando a los desarrolladores para otras tareas.

Desventajas:

El sistema se lanzó con una vulnerabilidad crítica, los clientes sufrieron.

Caso positivo

Un probador registró un error con la descripción del paso (abrir dos ventanas, secuencia de acciones), adjuntó una captura de pantalla y explicó por qué considera que esto es un error (un usuario real podría encontrarse en esta situación).