Cuánto tiempo debe asignarse para pruebas y solución de errores

Question

Cada vez que tengo que estimar el tiempo para un proyecto (o revisar el presupuesto de otra persona), se asigna tiempo para la prueba/corrección de fallas entre alfa y lanzamientos de producción . Sé muy bien que estimar tan lejos en el futuro con respecto a un conjunto de problemas de tamaño desconocido no es una buena receta para una estimación exitosa. Sin embargo, por una variedad de razones, invariablemente se asigna un número definido de horas al comienzo de este segmento de trabajo. Y cuanto más lejos esté esta estimación inicial del valor final real, mayor será el dolor que los involucrados en la depuración tendrán que tomar más adelante cuando pasen "por encima" de la estimación.

Así que mi pregunta es: ¿cuál es la mejor estrategia que ha visto con respecto a la realización de estimaciones como esta? ¿Un porcentaje fijo de la estimación del desarrollador global? Establecer el número de horas (con la expectativa de que suba) ¿Algo más?

Algo más a tener en cuenta: cómo respondería esto de manera diferente si el cliente es responsable de las pruebas (a diferencia del control de calidad interno) y debe asignar una cantidad de tiempo para responder a los errores que pueden o no encontrar (Así que necesita calcular las estimaciones de tiempo para la corrección de errores pero no para las pruebas)

Answer 1

Realmente depende de muchos factores. Por mencionar algunos: la metodología de desarrollo que está utilizando, la cantidad de recursos de prueba que tiene, la cantidad de desarrolladores disponibles en esta etapa del proyecto (muchos gerentes de proyectos moverán a las personas hacia algo nuevo al final).

Como Rob Rolnick dice que 1: 1 es una buena regla general, sin embargo, en casos donde una especificación es mala, el cliente puede presionar para buscar "errores" que en realidad son características mal especificadas. Hace poco estuve involucrado en un proyecto que usó muchos lanzamientos, pero se empleó más tiempo en la reparación de errores que en el desarrollo real debido a la terrible especificación.

Asegure una buena especificación/diseño y su tiempo de prueba/reparación de errores se reducirá porque será más fácil para los probadores ver qué y cómo probar y los clientes tendrán menos margen de maniobra para obtener características adicionales.

Answer 2

Tal vez simplemente escriba código defectuoso, pero me gusta tener una relación 1: 1 entre desarrolladores y pruebas. No espero hasta alfa para probar, sino que lo hago a lo largo de todo el proyecto. ¿La lógica? Dependiendo de su cronograma de lanzamiento, podría haber una buena cantidad de tiempo entre el inicio del desarrollo y las fechas alfa, beta y de envío. Además, cuanto antes detecte errores, más fácil (y más barato) es solucionarlos.

Un buen probador, que encuentra errores poco después de cada check-in, es invaluable. (O, mejor aún, antes de un check-in de un RP o DPK) En pocas palabras, todavía estoy muy familiarizado con mi código, por lo que la mayoría de las correcciones de errores se vuelven súper simples. Con este enfoque, tiendo a dejar aproximadamente el 15% de mi tiempo de desarrollo para corregir errores. Al menos cuando hago estimaciones. Entonces, en una carrera de 16 semanas, me iría unas 2-3 semanas.

Answer 3

Solo una buena cantidad de estadísticas acumuladas de proyectos anteriores pueden ayudarlo a proporcionar estimaciones precisas. Si tiene un conjunto de requisitos bien definidos, puede hacer un cálculo aproximado de cuántos casos de uso tiene. Como dije, necesitas tener algunas estadísticas para tu equipo. Necesita saber el número promedio de errores por bloque para estimar el número total de errores. Si no tiene esos números para su equipo, puede usar industry average numbers. Después de haber estimado el LOC (número de casos de uso * NLOC) y el promedio de errores por líneas, puede dar una estimación más o menos precisa del tiempo requerido para lanzar el proyecto.

Según mi experiencia práctica, el tiempo dedicado a corregir errores es igual o más (en 99% casos :)) que el tiempo empleado en la implementación original.

Answer 4

A partir de la prueba de la Biblia:

Testing Computer Software

p. 31: "Las cuentas de prueba [...] representan el 45% del desarrollo inicial de un producto". Una buena regla general es asignar aproximadamente la mitad de su esfuerzo total a las pruebas durante el desarrollo inicial.

Answer 5

Use un lenguaje con Diseño por contrato o "Contratos de código" (condiciones previas, verificaciones, postcondiciones, invariantes de clases, etc.) para obtener "pruebas" tan cerca de sus clases y características de clase (métodos y propiedades) como sea posible. Luego use TDD para probar su código con sus contratos.

Usa la mayor generación de código autoconstruida que puedas. El código generado es probado, predecible, más sencillo de depurar y más fácil/más rápido de corregir que el código codificado a mano. ¿Por qué escribir lo que puedes generar? Sin embargo, ¡no use OPG (generadores de personas ajenas)! El código que generas es el código que controlas y conoces.

Puede esperar invertir una proporción de inversión en el transcurso de su proyecto, es decir, escribirá muchos códigos manuales y contratos al inicio (1: 1) de su proyecto. Cuando vea patrones, enseñe un generador de códigos USTED ESCRIBE para generar el código para usted y reutilizarlo. Mientras más generes, menos diseñarás, escribiré, depuraré y probaré. Al final del proyecto, encontrará que su ecuación se ha invertido: está escribiendo menos de su código central, y su enfoque se desplaza a su "código de hoja" (última milla) o especializado (vs generalizado y generado código)

Finalmente, obtenga un analizador de código. Un buen sistema de reglas de análisis de código automatizado y motor le ahorrará montones de tiempo para encontrar "errores estúpidos" porque hay errores bien conocidos en la forma en que las personas escriben códigos en determinados idiomas. En Eiffel, ahora tenemos Eiffel Inspector, donde no solo usamos las más de 90 reglas que vienen con él, sino que estamos aprendiendo a escribir nuestras propias reglas para nuestros propios "errores" descubiertos. Dichos analizadores no solo lo salvan en términos de errores, sino que mejoran su diseño: incluso los programadores GREEN "lo obtienen" bastante rápido y dejan de cometer errores de novato antes y aprenden más rápido.

La regla de oro para reescribir sistemas existentes es esta: "Si tomó 10 años escribir, tomará 10 años volver a escribir". En nuestro caso, usando Eiffel, Diseño por contrato, Análisis de código y Generación de código, hemos reescrito un sistema de 14 años en 4 años y lo entregaremos por completo en 4 1/2. El nuevo sistema es aproximadamente 4x a 5x más complejo que el sistema anterior, ¡así que esto está diciendo mucho!