testing - tecnicas - herramientas de estimacion de proyectos de software
estimación del esfuerzo de prueba como porcentaje del tiempo de desarrollo (10)
¿Alguien usa una regla general para estimar el esfuerzo requerido para las pruebas como un porcentaje del esfuerzo requerido para el desarrollo? Y si es así, ¿qué porcentaje usas?
¿Está hablando de pruebas de unidad / integración automatizadas o pruebas manuales?
Para el primero, mi regla de oro (basada en las mediciones) es un 40-50% agregado al tiempo de desarrollo, es decir, si el desarrollo de un caso de uso demora 10 días (antes de que ocurra un control de calidad y una corrección de errores grave), escribir buenas pruebas demora entre 4 y 5 días. - aunque esto debería suceder mejor antes y durante el desarrollo, no después.
Cuando está estimando las pruebas, necesita identificar el alcance de las mismas: ¿estamos hablando de prueba unitaria, funcional, UAT, interfaz, seguridad, estrés de rendimiento y volumen?
Si estás en un proyecto de cascada, probablemente tengas algunas tareas generales que son bastante constantes. Permita tiempo para preparar cualquier documento de planificación, horarios 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 requiere al menos tanto esfuerzo para extraer de los requisitos / especificaciones / historias de usuario como lo llevará la ejecución. Además, debe incluir algún tiempo para la detección / reevaluación de defectos. Para un equipo más grande, deberá tener en cuenta la gestión de pruebas: programación, informes, reuniones.
En general, mis estimaciones se basan en la complejidad de las características que se entregan 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. Años de hacer pruebas me permiten descubrir que una prueba de una complejidad particular tomará x horas de esfuerzo para la preparación y ejecución. Algunas pruebas pueden requerir un esfuerzo adicional para la configuración de los datos. Algunas pruebas pueden implicar la negociación con sistemas externos y tienen una duración muy superior al esfuerzo requerido.
Sin embargo, al final, debe revisarlo en el contexto del proyecto en general. Si su estimación es muy superior a la de BA o Desarrollo, entonces puede haber algún error 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 constante para los gerentes de proyectos.
Cuando se habla de pruebas, podría significar el desarrollo de pruebas en cascada o ágiles. En un entorno ágil, los desarrolladores deberían dedicar el 50% de su tiempo a desarrollar y mantener pruebas.
Pero ese 50% adicional le ahorrará tiempo cuando llegue el momento de la re-factorización y la verificación manual.
Desde mi experiencia, el 25% del esfuerzo se gasta en Análisis; 50% para Diseño, Desarrollo y Test de Unidad; El 25% restante para la prueba. La mayoría de los proyectos se ajustarán a una variación de +/- 10% de esta regla de oro según la naturaleza del proyecto, el conocimiento de los recursos, la calidad de las entradas y salidas, etc. Se puede agregar una sobrecarga de gestión del proyecto dentro de estos porcentajes o como una Gastos generales en la parte superior dentro de un rango de 10-15%.
El blog de pruebas de Google discutió este problema recientemente :
Así que una respuesta ingenua es que la prueba de escritura conlleva un impuesto del 10%. Pero, pagamos impuestos para obtener algo a cambio.
(recorte)
Estos beneficios se traducen en valor real tanto hoy como mañana. Escribo pruebas, porque los beneficios adicionales que obtengo compensan con creces el costo adicional del 10%. Incluso si no incluyo los beneficios a largo plazo, el valor que obtengo de la prueba de hoy vale la pena. Soy más rápido en desarrollar código con test. Cuánto, bueno, eso depende de la complejidad del código. Cuanto más complejo sea lo que está intentando construir (más ifs / loops / dependencies), mayor será el beneficio de las pruebas.
El tiempo de prueba probablemente esté más relacionado con el alcance de la función que el tiempo de desarrollo. También argumentaría (quizás de manera controversial) que el tiempo de prueba se correlaciona con la habilidad de su equipo de desarrollo.
Para un esfuerzo de desarrollo de 6 a 9 meses, exijo un tiempo mínimo de prueba de 2 semanas, realizado por evaluadores reales (no el equipo de desarrollo) que están bien versados en el software que estarán probando (es decir, 2 semanas no no incluye el tiempo de aceleración). Esto es para un proyecto que tiene ~ 5 desarrolladores.
Gartner en octubre de 2006 afirma que las pruebas normalmente consumen entre el 10% y el 35% del trabajo en un proyecto de integración de sistemas. Supongo que se aplica al método de cascada. Este es un rango bastante amplio, pero hay muchas dependencias en la cantidad de personalizaciones de un producto estándar y la cantidad de sistemas que se integrarán.
Hace algunos años, en un campo crítico de seguridad, escuché algo así como un día para pruebas de unidad de diez líneas de código.
También he observado el 50% de esfuerzo para el desarrollo y el 50% para las pruebas (no solo las pruebas unitarias).
Juzga por el clima de ayer. ¿Cuánto tiempo tomó la última vez? ¿Tienes una tendencia más larga o más corta? Cada tienda es diferente.
La mayoría de las tiendas ágiles necesitan mucho menos tiempo, tienen menos defectos de manera drástica y un tiempo más rápido para resolverlos debido a TDD. Aun así, la mayoría de las tiendas ágiles tienen un tiempo medible dedicado a las pruebas / control de calidad.
Si esta es la primera ejecución de prueba para esta aplicación, entonces la respuesta es "veamos" seguido de un intento. Depende de qué tan rápido pueda obtener respuestas a sus preguntas, qué tan comprobable es, cuántas características / funciones se descubren, cuántos defectos se descubren, qué tan rápido se resuelven los problemas, cuántas veces el código pasa por las pruebas y cómo Muchas veces las pruebas están bloqueadas por errores. No hay manera de decirlo. Podrías llamarlo 50% o 175% o más, y no estar equivocado. ¿Por qué no hacer una conjetura 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.
La única vez que tomo en cuenta el tiempo extra para las pruebas es si no estoy familiarizado con la tecnología de prueba que usaré (p. Ej., Usar las pruebas de Selenium por primera vez). Luego tomo en cuenta quizás un 10-20% para ponerme al día con las herramientas y establecer la infraestructura de prueba.
De lo contrario, la prueba es solo una parte innata del desarrollo y no garantiza una estimación adicional. De hecho, probablemente aumentaría la estimación del código hecho sin pruebas.
EDITAR: Tenga en cuenta que por lo general escribo primero el código de prueba. Si tengo que entrar después del hecho y escribir pruebas para el código existente, eso va a ralentizar las cosas. No encuentro que el desarrollo de la primera prueba me frene en absoluto, excepto por la codificación muy exploratoria (leer: tirar).