Los errores funcionales están relacionados con la funcionalidad de un software. Ejemplos: un botón que no envía el formulario, la búsqueda que no reacciona a la entrada del usuario, la aplicación que se cierra inesperadamente. Cada vez que realizas una acción y el sitio web/aplicación no responde como esperabas, podría ser un problema funcional. Nuestra información limitada sobre los productos de nuestros clientes y la falta de conocimiento sobre sus implementaciones dificultan determinar si un comportamiento observado es intencional o en realidad un error. Realizar suposiciones basadas en la experiencia y analizar el comportamiento del producto probando diferentes escenarios puede ayudarte a encontrar respuesta.
Cómo determinar si el comportamiento de una aplicación es un error funcional:
Intenta determinar si una función está diseñada de una manera particular o si realmente está fallando. Pruébala por sí misma y en combinación con otras funciones para detectar posibles diferencias.
Piensa en cuáles podrían haber sido las intenciones del cliente y considera que el producto podría estar funcionando de acuerdo a cómo fue implementado.
Encuentra evidencia de que algo no está funcionando como debería. Respalda tu afirmación.
Ejemplo: Una funcionalidad de una tienda en línea funciona de manera diferente a otras tiendas en línea que conoces. Eso no significa que la funcionalidad esté rota. El cliente puede implementar su producto de la manera que desee.
Ejemplo: Afirmas que un campo de un formulario no se valida y por lo tanto es un error. ¿Hay alguna indicación de que el campo debería estar validado? Proporciona evidencia mostrando que el campo se valida en algunos casos pero no en otros. Si no proporcionas evidencia, es una afirmación no probada.
Un problema visual o de contenido se convierte en un problema funcional cuando obstaculiza una funcionalidad y, por lo tanto, debe informarse como un error funcional.
¿Una pieza de funcionalidad funciona de manera consistente en diferentes escenarios y sin problemas evidentes? Entonces probablemente esté destinada (no es un error) y simplemente sugieres un cambio (sugerencia de usabilidad).
Evaluación de la Severidad
Al evaluar el nivel de severidad funcional de un error, se deben considerar varios factores: el impacto funcional del problema, la magnitud del problema, si existen soluciones alternativas o si es un obstáculo, si hay posibles y notables pérdidas de ventas, y si se puede comparar este error con otros errores de la misma severidad.
Un enfoque directo es observar el impacto funcional del error. Piensa en cuán grave es que una función no esté disponible. La funcionalidad secundaria no bloqueará a los usuarios para que no persigan su objetivo, a diferencia de la funcionalidad principal rota. Pregúntate qué relevancia tiene esa funcionalidad en el contexto del producto completo.
La pregunta de cuántas personas, productos o elementos se ven afectados por un problema funcional es un factor determinante para la magnitud de un problema. ¿No reacciona, por ejemplo, el botón "Agregar al carrito" en todas las páginas de detalle de productos de una tienda en línea o solo en una en particular? ¿Un pequeño grupo de usuarios se ve afectado por el problema o todos?
Considera si puedes alcanzar tu objetivo a través de una ruta u opción alternativa, o si una funcionalidad sigue estando no disponible. Cuando de manera intuitiva y fácil encuentras una forma de evitar un error, esta solución alternativa te permite alcanzar tu objetivo. Un error con una solución alternativa recibe un nivel de severidad más bajo que un error equivalente sin solución alternativa. Finalmente, cuando no hay una solución alternativa para la funcionalidad principal rota, es un obstáculo.
Estimar una posible pérdida de ventas es un enfoque secundario, ya que a menudo solo puedes suponer cómo podrían reaccionar las personas ante un error. Sin embargo, ten en cuenta cuán alta es una posible pérdida. Hace una gran diferencia si el precio de un producto difiere en centavos o cientos de dólares.
Después de todo, también puedes comparar tu error con aquellos que el mismo líder de equipo ya aprobó en esta prueba para averiguar si tu nivel de severidad es apropiado.
Niveles de Severidad para Errores Funcionales:
BAJA:
Impacto mínimo en el uso del producto.
El producto muestra un comportamiento no intencionado, pero el uso general no se ve afectado.
Pocos usuarios, productos o elementos se ven afectados.
Una función/parte de la funcionalidad está rota o no disponible, pero hay una solución alternativa fácil que resuelve el problema.
ALTA:
Impacto grave en el uso del producto, pero la funcionalidad principal está intacta.
Un gran número de usuarios, productos o elementos se ven afectados.
Una funcionalidad no trivial está rota o no disponible y no existe una solución alternativa.
Una funcionalidad importante está rota o no disponible, pero existe una solución alternativa (por lo tanto, no es un obstáculo total).
CRÍTICA:
El error impide la funcionalidad central de la aplicación o sitio web.
Un obstáculo total impide al usuario continuar con un proceso principal, por ejemplo, el proceso de compra.
El error provoca una pérdida potencial y notable de ventas para la empresa que opera la aplicación o el sitio web.
Evaluaciones Comunes
Tenemos una lista de casos que tienen niveles de gravedad fijos. El esquema de evaluación anterior no se aplica a los casos en esa lista. Dado que la lista se actualizará con el tiempo, revísela regularmente.
Errores de Casos Límite
Los errores de casos límite ocurren cuando una funcionalidad se utiliza de manera inusual. La funcionalidad no está defectuosa cuando se utiliza con datos y acciones de usuario típicos. Aquí tienes algunos ejemplos:
Acciones instantáneas, como minimizar una aplicación después de hacer clic en un botón.
Repetir la misma acción varias veces, por ejemplo, abrir y cerrar menús.
Cualquier error que solo ocurra después de una serie no común de acciones.
Cada caso debe evaluarse por separado. Los errores de casos límite relevantes para nuestros clientes se consideran errores de baja importancia. Los casos irrelevantes, que son la mayoría de los errores de caso límite, serán rechazados.
Errores Forzados
Forzar un error mediante un comportamiento no típico o condiciones especiales está generalmente fuera del alcance de la prueba, ya que estos errores no son relevantes para nuestros clientes. El comportamiento no típico no refleja el comportamiento normal de los usuarios.
Estos son algunos ejemplos de comportamiento no típico o condiciones especiales:
Tocar múltiples elementos al mismo tiempo.
Presionar botones al azar.
Hacer clic rápidamente en un botón varias veces.
Reducir el tamaño de la ventana a tamaños no típicos.
Llenar la RAM o la memoria interna, lo que lleva a un comportamiento inesperado.
Usar versiones no oficiales, beta o modificadas del sistema operativo.