¿Cuántos detalles hay en una buena prueba de regresión de IU?

7

Utilizamos una prueba de regresión de la interfaz de usuario detallada paso a paso para nuestra aplicación web comercial. Tiene una prueba de "backbone" para las partes más usadas / más importantes del sistema, con pruebas opcionales para áreas específicas de funcionalidad. El uso de este plan definitivamente nos ha ayudado a garantizar software de alta calidad.

Pero, tener pruebas muy específicas puede ser contraproducente. El probador se concentra en seguir la prueba y omitirá por completo los problemas de usabilidad, o no notará problemas bastante obvios, como la parte inferior de una página que falta.

Por el contrario, algunas de las mejores pruebas de UI se producen cuando se crea una demostración de una nueva función. A menudo hago mis mejores pruebas pretendiendo demostrar el sistema a un prospecto imaginario. Sin embargo, cuando les digo a los evaluadores: "Solo demuéstrense el sistema", no cubren tanta funcionalidad como lo hacen con una prueba detallada punto por punto.

Se me pide repetidamente que proporcione más y más detalles en el plan de prueba para que un nuevo evaluador no capacitado pueda realizar pruebas con él sin hacer ninguna pregunta. Sin embargo, los detalles parecen ser contraproducentes. ¿Cuántos detalles pones en una prueba de regresión para hacerla efectiva? ¿Cómo se escriben las pruebas que hacen que el probador se centre más en el sistema que en marcar los elementos de la prueba?

    
pregunta GlenPeterson 31.08.2012 - 15:12

3 respuestas

5

Hablando técnicamente, una prueba de regresión no debería estar buscando problemas de usabilidad. Puede detectar desviaciones del diseño de la interfaz de usuario como parte de los casos de prueba, pero los especialistas en diseño de la interfaz de usuario determinan mejor los problemas de uso. Las pruebas de regresión de la IU normalmente se realizan por control de calidad (probadores), como saben.

Si el producto es demasiado grande para un diseño de interfaz de usuario detallado, el diseñador de la interfaz de usuario debe producir pautas que el equipo de desarrollo debe seguir y el control de calidad debe verificar. Por ejemplo, "Cada página debe contener un encabezado con A, B y C" o "Al solicitar una dirección, debe tener estos campos establecidos de esta manera".

Puede ser mejor proporcionar los pasos de verificación de la interfaz de usuario de una manera diferente. Por ejemplo, en lugar de dar pasos, incluya capturas de pantalla de la apariencia que debería tener la aplicación (lo que debería captar la parte inferior de la página que falta).

También puede considerar una herramienta de prueba de IU automatizada como Selenium . Esto puede automatizar gran parte del aspecto de las pruebas repetitivas que está capturando en los pasos y liberarlo a usted y a sus evaluadores para buscar problemas más difíciles de reproducir o más críticos.

    
respondido por el akton 31.08.2012 - 16:18
4

No puedes ordenar a alguien que sea innovador. Si solo tiene evaluadores en su equipo sin desarrollar ideas propias para buenas pruebas, no creo que un plan de pruebas mejor resuelva ese problema por usted. O necesitan más experiencia y capacitación, o necesitas personas diferentes en tu equipo.

Dijo que, creo que deberías tener ambos:

  1. una lista de verificación paso a paso muy detallada de las cosas en las que desea que los evaluadores tengan un ojo en

  2. algunas preguntas / pautas generales, por ejemplo, sobre la usabilidad de las pruebas o sobre cosas no mencionadas explícitamente en su plan, o una demanda para crear puntos faltantes en la lista de verificación por sí mismos.

Deje en claro que espera que su equipo no solo se centre en el punto 1, sino también en el punto 2, pero no espere demasiado por lo que escribí al principio.

    
respondido por el Doc Brown 31.08.2012 - 15:38
0

Si dice "demostrar el sistema", escucho los flujos de trabajo de los clientes: cómo el cliente va a utilizar el sistema.

Por lo general, al lado de algunas funciones básicas, como "se instala, inicia, etc.", encuentro que la prueba de UI es más útil para simular que un usuario real trabaja con el sistema.

Además, la mayoría de las veces, los automatizadores de UI obtienen sus especificaciones de algún otro lugar. Si no existe tal lugar / persona, puede pedirles que hablen con los clientes o con la administración del producto sobre cómo usan el sistema.

Esto también tiene la ventaja de que esté un poco más seguro de que el producto que envía está funcionando (al menos) en algunos escenarios del mundo real.

    
respondido por el Andreas Reiff 20.10.2015 - 15:35

Lea otras preguntas en las etiquetas