¿Cómo puedo decidir qué probar manualmente y en qué confiar para las pruebas automatizadas?

Question

Tenemos un montón de desarrolladores y solo unas pocas personas de control de calidad. Los desarrolladores se han involucrado cada vez más en qa durante todo el proceso de desarrollo al escribir pruebas automáticas, pero nuestras prácticas de control de calidad son principalmente manuales.

Lo que me gustaría es si nuestras prácticas de desarrollo fueran BDD y TDD y creciéramos un sólido conjunto de pruebas. La pregunta es: al construir un conjunto de pruebas de este tipo, ¿cómo podemos decidir en qué podemos confiar para las pruebas y qué debemos seguir probando manualmente?

Answer 1

La primera línea divisoria es - lo que es sustancialmente más fácil a prueba manualmente, y lo que es más fácil sustancialmente para probar de forma automatizada?

Esas son, por supuesto, bastante fáciles de adivinar, y probablemente se quede con una gran pila de guck en el medio.

Mi siguiente criba sería: los problemas de la interfaz de usuario están entre los más difíciles de probar de forma automática, aunque algunos proyectos lo están haciendo más fácil. Así que dejo eso a la gente de QA por un tiempo, y enfoco sus pruebas automatizadas en pequeñas unidades de código de back-end, expandiéndolo lentamente a pruebas de integración más grandes en múltiples unidades y/o múltiples niveles de su aplicación.

Answer 2

Mi consejo es que automatice todo lo que pueda automatizar. Deje que los humanos hagan lo que les hace bien, como responder a la pregunta "¿Este aspecto se ve, verdad?" o "¿Esto es útil?". Para todo lo demás, automatice.

Answer 3

+1 a Jim por recomendar la prueba manual de los elementos de la interfaz de usuario; es relativamente fácil usar una herramienta de automatización de UI para crear pruebas, pero se necesita mucha reflexión y anticipación para diseñar un marco de prueba que sea lo suficientemente robusto y completo como para minimizar el mantenimiento de las pruebas.

Si es necesario dar prioridad, un par de técnicas que he utilizado para identfiy áreas no interfaz de usuario que se beneficiarían más de las pruebas adicionales son:

1. mirada a los informes de errores de versiones anteriores, especialmente la errores reportados por los clientes si tiene acceso a ellos. Algunas áreas funcionales específicas a menudo representan la mayoría de los errores.
2. Use una herramienta de cobertura de código cuando ejecute las pruebas automáticas existentes y tome nota de las áreas con poca o ninguna cobertura.

Answer 4

Eche un vistazo al artículo de Mike Cohn sobre el Test Automation Pyramid. Específicamente, considere qué parte de la IU realmente debe probarse de esa manera. Los casos de esquina, por ejemplo, a menudo se prueban mejor a través de la capa de servicio.

Answer 5

No va a doler probar nuevas funcionalidades manualmente para asegurarse de que funcionen según los requisitos y luego agregarlas al paquete de automatización para la regresión. (¿O es demasiado tradicional?)

Answer 6

Las pruebas manuales puede hacer lo siguiente, a diferencia de las pruebas automatizadas:

• pruebas de interfaz gráfica de usuario de prueba
• Usabilidad
• pruebas exploratorias
• Use variaciones cuando se ejecutan pruebas
• encontrar nuevas, no de regresión errores
• El ojo humano puede notar todos los problemas. Una autoprueba solo verifica algunas cosas.

Las pruebas automatizadas pueden hacer lo siguiente, a diferencia de las pruebas manuales:

• Estrés/Pruebas de carga
• incluso se puede utilizar un conjunto de pruebas automatizado para probar el rendimiento
• prueba de la configuración (en mi humilde opinión esto es el mayor beneficio). Una vez escrito, puede ejecutar la misma prueba en diferentes entornos con diferentes configuraciones y descubrir dependencias ocultas que nunca pensó.
• Puede ejecutar la misma prueba a través de miles de datos de entrada. En el caso de las pruebas manuales, debe seleccionar el conjunto mínimo de datos de entrada usando diferentes técnicas.

Además, cometer un error en una autoprueba es más fácil y es más probable que cometa un error durante las pruebas manuales. Le recomiendo que automatice la funcionalidad más valiosa, pero de todos modos ejecute las pruebas (al menos, la cordura) manualmente antes de una versión importante.