¿Alguien usa una regla general para estimar el esfuerzo requerido para probar como un porcentaje del esfuerzo requerido para el desarrollo? Y si es así, ¿qué porcentaje usas?estimación del esfuerzo de prueba como un porcentaje del tiempo de desarrollo
Cuando está estimando las pruebas, necesita identificar el alcance de sus pruebas: ¿estamos hablando de pruebas unitarias, funcionales, UAT, interfaz, seguridad, tensión de rendimiento y volumen?
Si está en un proyecto de cascada, probablemente tenga algunas tareas generales que sean bastante constantes. Permita tiempo para preparar cualquier documento de planificación, programa e informes.
Para una fase de prueba funcional (soy un "probador del sistema", así que ese es mi principal punto de referencia) ¡no olvide incluir la planificación! Un caso de prueba a menudo necesita al menos el mismo esfuerzo para extraer de los requisitos/especificaciones/historias de usuario, ya que llevará a ejecutar. Además, debe incluir algo de tiempo para la generación/nueva prueba de defectos. Para un equipo más grande, deberá tener en cuenta la administración de pruebas: programación, informes y reuniones.
En general, mis estimaciones se basan en la complejidad de las características entregadas en lugar de en un porcentaje del esfuerzo de desarrollo. Sin embargo, esto requiere acceso a al menos un conjunto de instrucciones de alto nivel. Los años de prueba me permiten pensar que una prueba de una complejidad particular requerirá x horas de esfuerzo para la preparación y ejecución. Algunas pruebas pueden requerir un esfuerzo extra para la configuración de datos. Algunas pruebas pueden implicar la negociación con sistemas externos y tienen una duración muy superior al esfuerzo requerido.
Al final, sin embargo, debe revisarlo en el contexto del proyecto general. Si su estimación es muy superior a la de BA o Desarrollo, puede haber algún problema con sus suposiciones subyacentes.
Sé que este es un tema antiguo, pero es algo que estoy revisando en este momento y es de interés perenne para los gerentes de proyecto.
La Prueba de blogs de Google discussed this problem recently:
lo tanto una respuesta ingenua es que la escritura de prueba conlleva un impuesto del 10%. Pero, pagamos impuestos para obtener algo a cambio.
(SNIP)
Estos beneficios se traducen en un valor real de hoy, así como mañana. Escribo pruebas porque los beneficios adicionales que recibo compensan con creces el costo adicional del 10%. Incluso si no incluyo los beneficios a largo plazo, el valor que obtengo hoy de la prueba vale la pena. Soy más rápido en el desarrollo de código con prueba. Cuánto, bueno eso depende de la complejidad del código. Cuanto más complejo es lo que intenta crear (más ifs/loops/dependencias), mayor es el beneficio de las pruebas.
Hace algunos años, en un campo crítico de seguridad, he escuchado algo así como un día para probar unidades de diez líneas de código.
También he observado un 50% de esfuerzo para desarrollo y un 50% para pruebas (no solo pruebas unitarias).
¿Está hablando de pruebas de unidad/integración automatizadas o pruebas manuales? Para el primero, mi regla general (basada en mediciones) es 40-50% agregado al tiempo de desarrollo, es decir, si desarrollar un caso de uso demora 10 días (antes de que ocurra una garantía de calidad y una corrección de errores grave), escribir buenas pruebas toma otro De 4 a 5 días, aunque esto debería ocurrir antes y durante el desarrollo, no después.
Probablemente, el tiempo de prueba está más estrechamente relacionado con el alcance de la característica que con el tiempo de desarrollo. También argumentaría (quizás polémicamente) que el tiempo de prueba está correlacionado con la habilidad de su equipo de desarrollo.
Para un esfuerzo de desarrollo de 6 a 9 meses, exijo un mínimo absoluto de 2 semanas de tiempo de prueba, realizado por probadores reales (no el equipo de desarrollo) que están bien versados en el software que probarán (es decir, , 2 semanas no incluye tiempo de aceleración). Esto es para un proyecto que tiene ~ 5 desarrolladores.
La única vez que tomo en cuenta el tiempo adicional para las pruebas es si no estoy familiarizado con la tecnología de prueba que voy a usar (por ejemplo, usar las pruebas de Selenium por primera vez). Luego factoro tal vez un 10-20% para ponerme al día con las herramientas y poner en marcha la infraestructura de prueba.
De lo contrario, las pruebas son solo una parte innata del desarrollo y no justifican una estimación adicional. De hecho, probablemente aumentaría la estimación del código realizado sin las pruebas.
EDITAR: Tenga en cuenta que normalmente estoy escribiendo código de prueba primero. Si tengo que entrar después del hecho y escribir pruebas para el código existente, eso va a ralentizar las cosas. No creo que el desarrollo de prueba primero me ralentice en absoluto, excepto en la codificación muy exploratoria (lectura: descartable).
Cuando habla de pruebas, podría querer decir cascada o desarrollo de prueba ágil. En un entorno ágil, los desarrolladores deben dedicar el 50% de su tiempo a desarrollar y mantener las pruebas.
Pero ese 50% extra de voluntad ahorrar tiempo cuando viene la re-factoring y el tiempo de verificación manual.
Me estoy dando cuenta de que no he sido muy claro. Disculpas Me refiero en el contexto de la preparación de una oferta para un cliente y el uso de una metodología que es más cascada que ágil. Los clientes quieren saber cuál es el presupuesto. Necesitamos darles una figura realista pero, al mismo tiempo, protegernos de los innumerables millones de cosas desconocidas que hay por delante tan temprano en un proyecto. TENEMOS QUE ACEPTAR UNA CITA FIJA PARA ESPECIFICAR Y ALCANZAR EL PROYECTO; pero solo da una indicación de las iteraciones/fases que seguirán después de eso. –
Juzgue por el clima de ayer. ¿Cuánto tiempo tomó la última vez? ¿Tienes tendencia más larga o más corta? Cada tienda es diferente.
Las tiendas más ágiles necesitan mucho menos tiempo, tienen defectos drásticamente menores y un tiempo más rápido para resolverlas debido a TDD. Aun así, la mayoría de las tiendas ágiles tienen un tiempo medible dedicado a pruebas/control de calidad.
Si esta es la primera ejecución de prueba para esta aplicación, entonces la respuesta es "deja ver" seguido de un intento. Depende de lo rápido que puede conseguir preguntas contestadas, - cómo comprobable es, - ¿Cuántos características/funciones - ¿Cómo se descubren muchos defectos, - la rapidez con que se resuelven los problemas, - ¿Cuántas veces los ciclos de código a través de pruebas, y - cuántas veces la prueba está bloqueada por errores . No hay forma de saberlo. Podría llamarlo 50% o 175% o más, y no estar equivocado. ¿Por qué no hacer una suposición aproximada y multiplicar por Pi? No será mucho peor que cualquier otra respuesta que puedas inventar.
Debe (debe) saber cuánto tiempo lleva ahora y si se está volviendo más rápido o más lento, y si la cobertura está aumentando o disminuyendo. Con esos tres bits de información, deberías poder adivinar bastante bien.
Gartner en octubre de 2006 afirma que las pruebas generalmente consumen entre 10% y 35% del trabajo en un proyecto de integración de sistema. Supongo que se aplica al método de cascada. Este es un rango bastante amplio, pero existen muchas dependencias en cuanto a la cantidad de personalizaciones para un producto estándar y la cantidad de sistemas que se deben integrar.
Según mi experiencia, el 25% del esfuerzo se realiza en Análisis; 50% para diseño, desarrollo y prueba unitaria; el restante 25% para la prueba. La mayoría de los proyectos encajarán dentro de una variación de +/- 10% de esta regla de oro dependiendo de la naturaleza del proyecto, el conocimiento de los recursos, la calidad de las entradas & salidas, etc. Se puede agregar una sobrecarga administrativa de proyecto dentro de estos porcentajes o como un arriba en la parte superior dentro de un rango de 10-15%.
Para la seguridad crítica, también es una relación de 10 líneas de prueba para cada línea de código. –
¿Alguien tiene una referencia confiable para esta estadística? – Steztric