Tenemos un producto similar a Photoshop y tenemos muchos problemas en el período de prueba.
empezamos a usar Agile Framework, en medio del proyecto.
Tenemos que usar pruebas manuales humanas para probar los efectos visuales (por ejemplo, la función de opacidad de la imagen de fondo)
La prueba unitaria no es suficiente y no es aplicable para el lado visual (parte frontal) de la aplicación.
ahora estamos usando selenium para las pruebas de interfaz de usuario, pero no es suficiente, porque los evaluadores tienen que verificar las capturas de pantalla que tomó selenium. Y hay más de 500 capturas de pantalla para cada prueba de lanzamiento.
probamos las pruebas manuales pero nos perdimos muchos casos (por ejemplo, si el valor del índice z del botón es mayor que otros elementos, la opacidad del fondo del botón no funciona). Así que tuve una pregunta "¿cómo prueban las funciones de Photoshop en Adobe?".
¿Cómo debo probar una interfaz de usuario muy complicada?
Como Marv menciona en sus comentarios, esta es una pregunta muy amplia, pero intentaré plantear algunas ideas que podrían ser útiles (dada la amplitud de la pregunta, estoy seguro de que no serán exhaustivas).
En primer lugar, pruebe sobre la marcha. No espere hasta un período de prueba si puede evitarlo de alguna manera. Esto es realmente cierto para casi cualquier proyecto. El período de prueba se reduce y no hay suficiente tiempo para la prueba.
Desafíe a sus desarrolladores y evaluadores a identificar pruebas de nivel inferior para validar muchas de sus diversas funciones, especialmente en el nivel de prueba de integración. Por ejemplo, si quiero poder aclarar u oscurecer una región, debería poder crear una serie de casos de prueba automatizados para validar que se hayan realizado los cálculos correctos y se hayan realizado cambios en el color de los píxeles. Podría usar algo como Fitnesse para crear un gran conjunto de pruebas que prueben a fondo esta funcionalidad debajo de la capa de la interfaz de usuario.
Por supuesto, este trabajo también debe validarse en la interfaz de usuario, pero si ha verificado que todos los cálculos funcionan bajo el capó, solo necesita probar que los datos ingresan a la interfaz de usuario correctamente, lo que requiere muchas menos pruebas. Nuevamente, desafíe a su equipo a encontrar formas automatizadas de probar esto. Por ejemplo, un equipo con el que trabajé recientemente usó la coincidencia de imágenes para asegurarse de que, dada una determinada imagen de inicio y al establecer ciertos parámetros, obtendría la imagen resultante esperada.
Este tipo de trabajo lleva tiempo, pero también agrega mucha estabilidad. Si dedica tiempo a lo largo del proyecto para invertir en estas pruebas de regresión automatizadas, una cantidad sustancial de lo que ahora prueba manualmente se ejecutará en un fin de semana en una prueba automatizada y su prueba manual puede enfocarse en los escenarios extremadamente complejos y dinámicos con mucho tiempo para dedicarlo.
Como se indicó anteriormente, pruebe sobre la marcha:
¿Está utilizando un marco Agile que promueve las pruebas iterativas?
¿Cuál es su proceso de prueba actual? ¿Proceso de entrega? ¿Sus procesos promueven las pruebas tan pronto como se registra el código? ¿Antes?
¿Invierte en automatización de pruebas para cubrir escenarios comunes?
¿Ha mirado lo que debe, debe y podría probarse para determinar qué pruebas son más valiosas en términos de valor comercial?
¿Lanza una versión experimental o alfa de su producto a su base de usuarios con frecuencia? Si tiene recursos limitados, a veces es posible obtener pruebas "gratuitas" de la comunidad de usuarios finales.
Si responde "No" a cualquiera de las preguntas anteriores, tiene muchas oportunidades para mejorar su capacidad de prueba.
molinos marv
Todd A. Jacobs
ViSu
mst