2010-04-30 22 views

Respuesta

8

En general, las pruebas automatizadas tienen sentido bajo la condición de que la inversión total en establecer y mantener la prueba automatizada durante la vida del producto sea menor que la inversión total en la prueba manual cuando sea necesario durante la vida del producto.

Por lo tanto, las pruebas automáticas se vuelven más atractivas si es muy barato crear la prueba en comparación con ejecutarlas manualmente (por ejemplo, pruebas de ajuste en las que esencialmente se crean hojas de cálculo) o si habrá una cantidad suficiente de ejecuciones de la prueba para compensar la diferencia de costo.

Las pruebas unitarias funcionan bien porque hay un número suficiente de ejecuciones, con cada cambio menor o refactorización que desee para asegurarse de que no haya ningún fallo nuevo.

Las pruebas de aceptación son más difíciles debido a que la probabilidad de ejecución repetida cambia significativamente de un proyecto a otro, y las necesidades del negocio afectan los problemas de mantenimiento y soporte a largo plazo.

Si un proyecto se entrega una vez que pasa las pruebas de aceptación y no hay más soporte o cambios, entonces las pruebas de aceptación automatizada pueden no tener sentido a menos que sea muy barato producir las pruebas automatizadas.

Si, por otro lado, uno espera futuras versiones (incluso para el mismo cliente) o un contrato de soporte a largo plazo, entonces la inversión inicial puede valer la pena con el tiempo.

Nuestra empresa produce sistemas de trading y algoritmos para una variedad de clientes, y las nuevas características y productos se construyen sobre los antiguos. El costo de ejecutar todas nuestras pruebas manualmente es tan alto, que estamos trabajando para agregar pruebas de aceptación automáticas para muchos escenarios que previamente se han probado manualmente.

Seguimiento:

en mi humilde opinión, es importante primero tener planes de prueba paso a paso muy claras y completas (Una buena persona o un equipo de control de calidad es crítica aquí). En el caso de las pruebas de aceptación, los clientes pueden proporcionar las suyas propias o QA debería proporcionarlas a sus clientes. Creo que un plan de prueba a menudo debe ser parte del contrato.

Una vez que tenga eso, es más fácil estimar cuánto le tomaría a un humano ejecutarlo (y puede experimentar con un ser humano para averiguarlo). Es importante prestar atención a los pasos que requieren un "trabajo pesado", y qué pasos requieren un aporte o discreción humana real.

Esta es una distinción importante. Por ejemplo, supongamos que está creando un programa de dibujo. si le dices a un humano que dibuje líneas en coordenadas específicas, esto se puede automatizar fácilmente. Sin embargo, si su paso dice: "Verifique que la forma sea una flor", un humano puede hacerlo fácilmente pero automatizarlo es casi imposible. Muchos casos de prueba pueden ser semiautomatizados. Dejas "ganchos" para la entrada del usuario y haces que el probador se centre en ellos.Un botón inicia una serie de operaciones y se le presenta al usuario "¿salió la salida correcta?".

Mi experiencia es que el costo de la automatización es bastante intuitivo. Sin embargo, a menudo es necesario modificar el programa existente para hacerlo más comprobable. Por ejemplo, en el ejemplo anterior, si tiene una API que le permite agregar líneas al lienzo, las cosas son geniales. Si tiene que escribir un robot de ratón que traduce coordenadas lógicas a la pantalla y todo eso, es mucho más largo.

+0

Gracias, exactamente mis pensamientos :) Sin embargo, no pensé en un escenario real en el que sería útil ejecutar la aceptación prueba más veces. Todavía tengo algunas preguntas: ¿cómo determinar el costo de las pruebas automáticas frente a las pruebas manuales? ¿Has pensado en tu escenario sobre las pruebas basadas en modelos? –

+1

Gabriel, en mi humilde opinión, es importante tener primero planes de prueba paso a paso muy claros y completos (una buena persona de control de calidad es útil aquí). Una vez que tienes eso, es más fácil estimar cuánto tiempo le tomaría a un humano ejecutarlo (y puedes experimentar con humanos). Si el tiempo es muy largo, entonces realiza un análisis de ingeniería del costo para automatizar. A menudo es bastante intuitivo, aunque podría requerir algunos cambios en la infraestructura para que las cosas sean más comprobables. – Uri

+0

de hecho, creo que la capacidad de prueba debe ser un requisito arquitectónico desde el principio, gracias, ese último párrafo hizo mi pase de prueba de aceptación de respuesta :). –

3

¿Cuáles son los beneficios de la automatización de las pruebas de aceptación de ?

A menudo soy una tienda de un solo hombre, por lo que, desde mi punto de vista, el beneficio principal es que las máquinas lo hagan en lugar de mí.

+0

¿De qué manera es más fácil probar el marco de prueba, escribir pruebas en la biblioteca y escribir pruebas automatizadas que las pruebas manuales? Creo que el mayor problema es que las pruebas de aceptación a menudo se ejecutan solo una vez, ¿estoy en lo cierto? –

+0

@Gabriel, Um ... el aprendizaje es la parte más difícil ya menos que tengas topes de goma entre tus orejas, solo necesitas hacerlo una vez. el resto es académico Y tiene un punto válido si tiene y solo tendrá una versión de un producto. Si tan solo tuviera tanta suerte. –

+0

@Gabriel: también, mi definición de pruebas de aceptación incluye pruebas de humo y bordes en pruebas funcionales, por lo que puede que mi definición sea poco estricta. ¿Qué sé, de todos modos? ;-) –

3

Escribir pruebas de aceptación automatizadas puede obtener grandes beneficios. En particular, se hará lo siguiente:

  • Mejorar la confianza del cliente en un producto que ha demostrado ser estable
  • menores costos de mantenimiento
  • reducir el riesgo y el miedo al cambio
  • la estabilidad y precisión y cambios más baratas para el sistema

Si bien puede estar 100% familiarizado con la aplicación ahora, intente dejarla de lado durante algunos meses o años y vuelva a ella para realizar cambios. Créanme, es mucho más fácil poder ejecutar un conjunto de pruebas para demostrar que sus nuevos cambios no han roto nada.

Finalmente, considere escribir sus pruebas de aceptación antes de escribir el código, a la moda de prueba de desarrollo impulsado. Esto no solo le dará un mejor código, sino que tendrá una cobertura completa de suite de pruebas cuando termine.

No se engañe sobre los costos. Sí, toma tiempo, compromiso y energía escribir y mantener un conjunto de pruebas de aceptación automática. Pero esto es más barato que la alternativa, que no es ninguna prueba ni idea de qué sucede si cambias algo y qué efecto de golpe tendrá. ¿Cuál es la confianza de su cliente? ¿Cuál es el costo real de corregir un error después de su envío?

+0

¿De qué manera mi cliente tiene más confianza en la estabilidad del sistema? ¿Qué pasa con las pruebas automatizadas que hacen que mi sistema sea estable? ¿Qué costos de mantenimiento se ahorrarán? Las pruebas automatizadas se pueden ver como más código para mantener, que es todo lo contrario. Admito que el riesgo de cambio es menor, porque puedo ver qué escenarios se ven afectados por el cambio. No creo que el cambio sea más económico, a menudo también tiene que cambiar las pruebas. Escribir pruebas de aceptación de antemano puede ser difícil si no hay soporte para probar todas las interacciones. El costo no es problema para mí, pero ¿qué pasa con el cliente que paga? –

+0

En mi empresa, el cliente es el negocio que paga por la aplicación que se construirá, pero el punto es que si el cliente final ve constantemente un sistema estable, es más feliz lo que es valioso. Las pruebas automatizadas hacen que el sistema sea estable al identificar los errores de manera temprana, lo que ayuda a evitar que los problemas inesperados se recorten en sus compilaciones o permite la identificación temprana cuando lo hacen. El cambio es más económico porque es menos probable que se introduzcan errores que pueden ser costosos de solucionar y se requieren menos pruebas de regresión manual después de realizar el cambio. Finalmente, las pruebas bien escritas evitan un alto mantenimiento de la prueba. –

+0

El cliente que paga siempre se preocupa por el costo. Lo que es importante es que al pagar más por adelantado están evitando escenarios costosos e inesperados en el futuro (ya sea por tiempo de inactividad debido a fallas o plazos perdidos porque las pruebas de regresión manual toman más tiempo). Piense en ello como hacer que le revisen el automóvil regularmente. Al hacerlo, identifica los problemas más temprano, lo que le permite presupuestar tiempo y dinero para abordar cualquier problema temprano en lugar de descomponerlo inesperadamente, lo que cuesta mucho más tiempo y dinero y quién sabe qué más (tal vez conducía a una boda, por ej.) –

Cuestiones relacionadas