Las pruebas de UI manuales surgieron inicialmente como una necesidad, ya que las herramientas automáticas tienen dificultades para captar errores relacionados con la percepción visual y la facilidad de uso de la interfaz (historia). Todos los elementos deben ser accesibles, mostrarse correctamente e interactuar de acuerdo con las expectativas del usuario.
El principal problema de las pruebas manuales de UI es la evaluación subjetiva: diferentes personas pueden percibir la misma interfaz de diferentes maneras. Además, es frecuente que los defectos visuales no se documenten o se ignoren (‘problema’). Para evitar la subjetividad, es necesario desarrollar criterios claros de aceptación de elementos visuales, utilizar isométricos y guías, y documentar los problemas encontrados mediante capturas de pantalla, descripciones claras y comparaciones con los diseños originales (‘solución’).
Características clave:
¿Es suficiente verificar la UI solo en un navegador o en un dispositivo?
No, los elementos pueden mostrarse de manera diferente debido a las diferencias en los motores de los navegadores y las resoluciones de los dispositivos.
Si el probador no ve un defecto, ¿puede considerar que el error no existe?
No, es necesario comparar la interfaz con las guías y los diseños, y no solo confiar en su percepción subjetiva.
¿Se pueden ignorar los requisitos de accesibilidad (accessibility) al probar la UI?
No, los requisitos de accesibilidad son importantes para los usuarios finales, incluidas las personas con discapacidades.
El probador solo revisó la UI en su computadora y en un navegador, y también comparó visualmente con una versión anterior, sin basarse en el diseño. Como resultado, los usuarios de dispositivos móviles vieron una interfaz rota.
Pros:
Contras:
El probador verificó la UI en diferentes dispositivos y navegadores, comparó con el diseño, y tuvo en cuenta las guías de accesibilidad. Utilizó listas de verificación de criterios visuales.
Pros:
Contras: