Respuesta

Historia de la pregunta:

Las pruebas de aspectos no funcionales surgieron cuando se hizo evidente que incluso una funcionalidad que operaba perfectamente desde el punto de vista lógico puede ser inconveniente, lenta o inaccesible para parte de los usuarios. Estos defectos son difíciles de detectar automáticamente, por lo que los testers manuales juegan un papel clave aquí.

Problema:

Los testers a menudo se enfocan solo en la funcionalidad, ignorando el rendimiento, la usabilidad y la accesibilidad. Los defectos no funcionales son difíciles de formalizar y explicar, su subjetividad dificulta obtener una evaluación clara.

Solución:

Durante las pruebas, es importante dedicar tiempo deliberadamente a las verificaciones no funcionales. Para el rendimiento, registre el tiempo de respuesta (por ejemplo, con un cronómetro), para la usabilidad describa las incomodidades y proporcione ejemplos, para la accesibilidad utilice listas de verificación o herramientas (por ejemplo, incluya un lector de pantalla).

Características clave:

Requieren una clara formulación de criterios de aceptación.
Los resultados de la evaluación son a menudo subjetivos, por lo que es importante la fundamentación de los informes.
No todos estos defectos son aceptables antes del lanzamiento: algunos son críticos.

Preguntas engañosas.

¿Todos los defectos no funcionales deben ser registrados como bugs por el tester?

No siempre. Si el problema es subjetivo, a veces es suficiente discutirlo con el equipo y documentarlo como una mejora (solicitud de característica).

¿Debería el tester establecer métricas de rendimiento por sí mismo?

Solo si no están especificadas en los requisitos o en el pliego de condiciones, de lo contrario, hay que basarse en ellas.

¿Es obligatorio tener software o herramientas especiales para las pruebas no funcionales?

No, las pruebas básicas pueden hacerse manualmente (por ejemplo, medir el tiempo manualmente, analizar la accesibilidad con una lista de verificación).

Errores comunes y anti-patrones

Ignorar criterios no funcionales.
Informes subjetivos sin pruebas medibles.
Nombres y descripciones de bugs demasiado generales o vagos.

Ejemplo de la vida real

Caso negativo

El tester notó que la página del catálogo tarda más de 10 segundos en cargar, pero no registró un bug, suponiendo que “así es probablemente para todos”.

Ventajas:

No abrumó al equipo con tickets discutibles.

Desventajas:

Se redujo la experiencia del usuario, los clientes quedaron decepcionados, la gerencia se enteró del problema a través de quejas.

Caso positivo

El tester documentó detalladamente que la página del catálogo tarda 12 segundos en cargar en el primer acceso, adjuntó una captura de pantalla del cronómetro y sugirió posibles opciones de optimización.