¿Cuánto tiempo se debe asignar para las pruebas y la corrección de errores? [cerrado]

Question

Cada vez que tengo que estimar el tiempo para un proyecto (o revisar el estimado de otra persona), se asigna tiempo para las pruebas/corrección de errores que se realizarán entre las versiones alfa y de producción.Sé muy bien que estimar un futuro tan lejano respecto de un conjunto de problemas de tamaño desconocido no es una buena receta para una estimación exitosa.Sin embargo, por diversas razones, siempre se asigna un número definido de horas al principio a este segmento de trabajo.Y cuanto más se aleje esta estimación inicial del valor final real, más dolor tendrán que soportar los involucrados en la depuración más adelante cuando "superen" la estimación.

Entonces mi pregunta es:¿Cuál es la mejor estrategia que has visto con respecto a hacer estimaciones como esta?¿Un porcentaje fijo de la estimación general de desarrollo?¿Establecer el número de horas (con la expectativa de que aumente)?¿Algo más?

Algo más a considerar:¿Cómo respondería a esto de manera diferente si el cliente es responsable de las pruebas (a diferencia del control de calidad interno) y usted tiene que asignar una cantidad de tiempo para responder a los errores que pueden encontrar o no (por lo que necesita calcular las estimaciones de tiempo? para corregir errores pero no para realizar pruebas)

Answer 1

Realmente depende de muchos factores.Por mencionar sólo 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 proyecto trasladarán a las personas a algo nuevo al final).

Como dice Rob Rolnick, 1:1 es una buena regla general; sin embargo, en los casos en que una especificación es mala, el cliente puede buscar "errores" que en realidad son características mal especificadas.Recientemente estuve involucrado en un proyecto que utilizó muchas versiones, pero se dedicó más tiempo a corregir errores que al desarrollo real debido a la terrible especificación.

Asegúrese de tener una buena especificación/diseño y el tiempo de prueba/solución de errores se reducirá porque será más fácil para los evaluadores ver qué y cómo probar y los clientes tendrán menos margen de maniobra para solicitar funciones adicionales.

Answer 2

Tal vez simplemente escribo código con errores, pero me gusta tener una proporción de 1:1 entre desarrolladores y pruebas.No espero hasta alfa para realizar la prueba, sino que lo hago durante todo el proyecto.¿La lógica?Dependiendo de su calendario de lanzamiento, puede 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 los errores, más fácil (y económico) será solucionarlos.

Un buen evaluador, que encuentre errores poco después de cada registro, es invaluable.(O, mejor aún, antes de un registro de un PR 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, dejaría alrededor de 2 a 3 semanas.

Answer 3

De la Biblia de prueba:

Prueba de software informático

pag.31:"La prueba [...] representa el 45% del desarrollo inicial de un producto". Por lo tanto, una buena regla general es asignar aproximadamente la mitad de su esfuerzo total para probar durante el desarrollo inicial.

Answer 4

Sólo una buena cantidad de estadísticas acumuladas de proyectos anteriores pueden ayudarle a dar estimaciones precisas.Si tiene un conjunto de requisitos bien definido, puede hacer un cálculo aproximado de cuántos casos de uso tiene.Como dije, necesitas tener algunas estadísticas para tu equipo.Necesita conocer el número promedio de errores por ubicación para estimar el recuento total de errores.Si no tiene dichos números para su equipo, puede usar números promedio de la industria.Una vez que haya estimado el LOC (número de casos de uso * NLOC) y el promedio de errores por línea, puede dar una estimación más o menos precisa del tiempo necesario para lanzar el proyecto.

Desde mi experiencia práctica, el tiempo dedicado a corregir errores es igual o mayor (en el 99% de los casos :)) que el tiempo dedicado a la implementación original.

Answer 5

Utilice un lenguaje con Diseño por contrato o "contratos de código" (condiciones previas, aserciones de verificación, condiciones posteriores, invariantes de clase, etc.) para realizar "pruebas" lo más cerca posible de sus clases y características de clase (métodos y propiedades). posible.Luego use TDD para probar su código con sus contratos.

Utilice tanto código de generación propia como sea posible.El código generado es probado, predecible, más fácil de depurar y más fácil/rápido de corregir que el código totalmente codificado a mano.¿Por qué escribir lo que puedes generar?Sin embargo, ¡no utilice OPG (generadores de otros pueblos)!El código que TÚ generas es un código que tú controlas y conoces.

Puede esperar gastar 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.A medida que vea patrones, enseñe a un generador de código que USTED ESCRIBE a generar el código por usted y reutilizarlo.Cuanto más genera, menos diseña, escribe, depura y prueba.Al final del proyecto, encontrarás que tu ecuación se ha invertido:Está escribiendo menos código central y su atención se centra en su "código hoja" (última milla) o código especializado (frente a código generalizado y generado).

Finalmente, obtenga un analizador de código.Un buen sistema y motor de reglas de análisis de código automatizado le ahorrará mucho tiempo buscando "errores estúpidos" porque existen errores bien conocidos en la forma en que las personas escriben código en lenguajes particulares.En Eiffel, ahora tenemos Eiffel Inspector, donde no solo usamos las más de 90 reglas que vienen con él, sino que también aprendemos a escribir nuestras propias reglas para nuestros propios "errores" descubiertos.Estos analizadores no sólo le ahorran errores, sino que también mejoran su diseño: ¡incluso los programadores VERDES lo "entienden" bastante rápido y dejan de cometer errores de novato antes y aprenden más rápido!

La regla general para reescribir sistemas existentes es la siguiente:"Si tardó 10 años en escribir, tomará 10 años reescribir". En nuestro caso, utilizando Eiffel, diseño por contrato, análisis de código y generación de códigos, hemos reescrito un sistema de 14 años en 4 años y entregaremos completamente en 4 1/2.El nuevo sistema es entre 4 y 5 veces más complejo que el antiguo, ¡así que esto dice mucho!