La rentabilidad relativa del desarrollo impulsado por pruebas (de aceptación)

15

Me gustaría saber cuál es el impacto general de la planificación de recursos en un proyecto de software, donde los requisitos y el diseño del proyecto se basan en pruebas de aceptación automatizadas y pruebas unitarias, en contraste con un enfoque más "tradicional" para el desarrollo de software.

ingrese la descripción de la imagen aquí

¿Cuál es, en su experiencia, el efecto general sobre los requisitos de recursos para completar un proyecto de software bajo TDD, en oposición a las metodologías de desarrollo más "tradicionales"? Me parece evidente que la calidad aumentaría, y la cantidad de incertidumbre disminuye porque las pruebas se realizan antes, pero requerir pruebas por adelantado parece que requeriría más horas de desarrollador para lograrlo. ¿Cuánto aumenta el esfuerzo de desarrollo, o en realidad disminuye debido a la eliminación inicial de errores?

¿Cuánto más esfuerzo se requiere del cliente? ¿Tienen que cambiar la forma en que se relacionan con el proyecto, especialmente si están acostumbrados a grandes diseños desde el principio? ¿El número de horas requeridas por el cliente en general aumenta o realmente disminuye?

Me imagino que las estimaciones de tiempo serían muy vagas en un proceso iterativo de TDD al comienzo de un proyecto TDD (ya que no existe un Plan de Desarrollo de Software). ¿Hay un punto, digamos, del 20% en un proyecto, donde la confianza aumenta lo suficiente como para que se pueda proporcionar al cliente una estimación de tiempo y dinero más o menos estable?

Nota: No estoy buscando opiniones o teorías subjetivas aquí, así que no especules. Estoy buscando más experiencia en el mundo real en TDD.

Robert Harvey
fuente
Estoy seguro de que no hay datos del mundo real. Solo obtienes opiniones y teorías subjetivas basadas en la experiencia del mundo real de las personas.
Eufórico el
1
@Euphoric: Estoy buscando observaciones objetivas y realidades basadas en la experiencia del mundo real. Lo siento, no lo dejé claro. Sin embargo, no necesito números duros; Aceptaré impresiones generales tales como: "aunque nuestro tiempo de desarrollo aumentó sustancialmente, nuestros costos de mantenimiento disminuyeron porque el software era más confiable y el cliente lo entendió mejor porque participaron en el diseño durante todo el esfuerzo de desarrollo".
Robert Harvey
2
Entonces, ¿es esta una pregunta basada en una opinión? Ciertamente suena como uno
B 29овић
@ BЈовић: Vea el último párrafo en el cuerpo de mi pregunta.
Robert Harvey

Respuestas:

11

Lo primero que hay que decir es que TDD no necesariamente aumenta la calidad del software (desde el punto de vista del usuario). No es una bala de plata. No es una panacea. Disminuir el número de errores no es por eso que hacemos TDD.

TDD se realiza principalmente porque da como resultado un mejor código. Más específicamente, TDD da como resultado un código que es más fácil de cambiar .

Si desea o no usar TDD depende más de sus objetivos para el proyecto. ¿Será este un proyecto de consultoría a corto plazo? ¿Está obligado a apoyar el proyecto después de la puesta en marcha? ¿Es un proyecto trivial? La sobrecarga agregada puede no valer la pena en estos casos.

Sin embargo, según mi experiencia, la propuesta de valor para TDD crece exponencialmente a medida que el tiempo y los recursos involucrados en un proyecto crecen linealmente.

Las buenas pruebas unitarias ofrecen las siguientes ventajas:

  1. Las pruebas unitarias advierten a los desarrolladores de efectos secundarios no deseados.
  2. Las pruebas unitarias permiten un rápido desarrollo de nuevas funcionalidades en sistemas antiguos y maduros.
  3. Las pruebas unitarias brindan a los nuevos desarrolladores una comprensión más rápida y precisa del código.

Un efecto secundario de TDD podría ser menos errores, pero desafortunadamente, según mi experiencia, la mayoría de los errores (particularmente los más desagradables) generalmente son causados ​​por requisitos poco claros o deficientes o no estarían necesariamente cubiertos por la primera ronda de pruebas unitarias.

Resumir:

El desarrollo en la versión 1 podría ser más lento. El desarrollo en la versión 2-10 será más rápido.

Stephen
fuente
1
Me gusta que la yuxtaposición explícita de "mejor código" sea diferente de aumentar "la calidad del software", es decir, que lo que los programadores valoran en el código no es necesariamente que haga lo que el cliente quiere.
1
¿No se supone que las pruebas de aceptación por adelantado y las pruebas unitarias aclaran los requisitos?
Robert Harvey
@RobertHarvey Deberían ser, pero no necesariamente . Las pruebas unitarias y las pruebas de aceptación reflejarán la comprensión del desarrollador de los requisitos cuando se escriben. Los desarrolladores pueden tener cualquier cosa, desde una comprensión completa hasta la no comprensión de los requisitos cuando comienzan a escribir el software. Esa parte de la ecuación depende mucho más del cliente y gerente de producto que cualquier otra cosa. Teóricamente, las pruebas deberían ayudar mucho. En la práctica, bueno, "depende".
Stephen
1
Debo aclarar, estamos hablando de TDD de forma aislada aquí, no una implementación SCRUM que incorpora TDD. En forma aislada, TDD se trata de escribir pruebas para que pueda escribir un mejor código y pueda refactorizar más rápido y con mayor seguridad más adelante.
Stephen
1
@Stephen: Quizás debería haber dejado más claro que estoy hablando del sabor de TDD que incorpora pruebas de aceptación como parte del proceso de recopilación de requisitos. Agregué un gráfico a la pregunta para aclararlo.
Robert Harvey
6

Hay un capítulo en Making Software sobre Test-Driven Development, que cita el artículo discutido aquí .

Se llevaron a cabo estudios de caso con tres equipos de desarrollo en Microsoft y uno en IBM que adoptaron TDD. Los resultados de los estudios de caso indican que la densidad de defectos previos al lanzamiento de los cuatro productos disminuyó entre 40% y 90% en relación con proyectos similares que no utilizaron la práctica de TDD. Subjetivamente, los equipos experimentaron un aumento del 15–35% en el tiempo de desarrollo inicial después de adoptar TDD.

Si estos resultados son generalizables para su caso es, por supuesto, algo que los defensores de TDD argumentarán es obvio y los detractores de TDD argumentarán que no es cierto.


fuente
44
El problema con ese estudio es que no probaron el código de la unidad antes de adaptar TDD. TDD no es una herramienta mágica que reduce el número de defectos en un 40-90% simplemente adoptándolo
BЈовић
1
@ BЈовић No creo que digan "magia" en ninguna parte de ese documento. Afirman que algunos equipos adoptaron TDD, otros no, se les dio un trabajo "similar" y se registraron algunas densidades de defectos y tiempos de desarrollo. Si hubieran forzado a los equipos que no son TDD a escribir pruebas unitarias de todos modos para que todos tuvieran pruebas unitarias, no sería un estudio ecológicamente válido.
¿Un estudio ecológicamente válido? Sorta depende de lo que estés midiendo. Si desea saber si escribir sus pruebas por adelantado es importante, entonces todos deben escribir pruebas unitarias, no solo el grupo TDD.
Robert Harvey
1
@robert Harvey, es una cuestión de variables de confusión, no de validez ecológica. Diseñar un buen experimento implica degradarlos. Por ejemplo, si el grupo de control escribiera pruebas unitarias post hoc, las personas argumentarían que el experimento no fue sólido porque el grupo de control estaba trabajando de una manera poco común en la naturaleza.
2
Por suerte no dije que lo fueran.
5

No tengo ningún documento de investigación o estadística que darle, pero relataré mi experiencia de trabajar en un equipo / organización que históricamente tuvo una cobertura de prueba unitaria de baja a media y sin pruebas de punta a punta, y gradualmente moviendo la barra a donde estamos ahora, con un enfoque más de ATDD (pero, irónicamente, no TDD tradicional).

Específicamente, así es como se desarrollaban los cronogramas del proyecto (y aún se juegan en otros equipos / productos en la misma organización):

  • Hasta 4 semanas de análisis e implementación.
  • 2 semanas de pruebas de regresión, corrección de errores, estabilización y preparación de lanzamiento
  • 1-2 semanas de reparación de defectos conocidos
  • 2-3 semanas de limpieza de código y problemas / soporte de posproducción (defectos desconocidos / interrupciones no planificadas)

Esto parece una sobrecarga ridícula , pero en realidad es muy común, a menudo está enmascarado en muchas organizaciones por falta de control de calidad o ineficaz. Tenemos buenos evaluadores y una cultura de pruebas intensivas, por lo que estos problemas se detectan temprano y se solucionan por adelantado (la mayoría de las veces), en lugar de permitir que se desarrollen lentamente en el transcurso de muchos meses / años. La sobrecarga de mantenimiento del 55-65% es inferior a la norma comúnmente aceptada del 80% del tiempo dedicado a la depuración, lo cual parece razonable, porque teníamos algunas pruebas unitarias y equipos multifuncionales (incluido el control de calidad).

Durante el primer lanzamiento de nuestro equipo de nuestro último producto, habíamos comenzado a actualizar las pruebas de aceptación, pero no estaban a la altura del tabaco y todavía teníamos que confiar en muchas pruebas manuales. El lanzamiento fue algo menos doloroso que otros, IMO en parte debido a nuestras pruebas de aceptación al azar y también en parte debido a nuestra muy alta cobertura de pruebas unitarias en relación con otros proyectos. Aún así, pasamos casi 2 semanas en regresión / estabilización y 2 semanas en problemas de posproducción.

Por el contrario, cada lanzamiento desde ese lanzamiento inicial ha tenido criterios de aceptación temprana y pruebas de aceptación, y nuestras iteraciones actuales se ven así:

  • 8 días de análisis e implementación
  • 2 días de estabilización
  • 0-2 días combinados de soporte de postproducción y limpieza

En otras palabras, progresamos de 55-65% de gastos generales de mantenimiento a 20-30% de gastos generales de mantenimiento. El mismo equipo, el mismo producto, la principal diferencia es la mejora progresiva y la racionalización de nuestras pruebas de aceptación.

El costo de mantenerlos es, por sprint, 3-5 días para un analista de control de calidad y 1-2 días para un desarrollador. Nuestro equipo tiene 4 desarrolladores y 2 analistas de control de calidad, por lo que (sin contar UX, gestión de proyectos, etc.) eso es un máximo de 7 días hábiles de 60, que redondearé a una sobrecarga de implementación del 15% solo para estar en El lado seguro.

Dedicamos el 15% de cada período de lanzamiento a desarrollar pruebas de aceptación automatizadas, y en el proceso podemos reducir el 70% de cada lanzamiento haciendo pruebas de regresión y reparando errores de preproducción y posproducción.

Es posible que haya notado que la segunda línea de tiempo es mucho más precisa y también mucho más corta que la primera. Eso es posible gracias a los criterios de aceptación y las pruebas de aceptación iniciales, ya que simplifica enormemente la "definición de hecho" y nos permite tener mucha más confianza en la estabilidad de una versión. Ningún otro equipo (hasta ahora) ha tenido éxito con un cronograma de lanzamiento quincenal, excepto tal vez cuando se realizan lanzamientos de mantenimiento bastante triviales (solo corrección de errores, etc.).

Otro efecto secundario interesante es que hemos podido adaptar nuestro calendario de lanzamientos a las necesidades comerciales. Una vez, tuvimos que alargarlo a aproximadamente 3 semanas para que coincidiera con otra versión, y pudimos hacerlo mientras brindamos más funcionalidad pero sin gastar tiempo adicional en pruebas o estabilización. En otra ocasión, tuvimos que acortarlo a aproximadamente 1½ semanas, debido a días festivos y conflictos de recursos; tuvimos que asumir menos trabajo de desarrollo, pero, como era de esperar, pudimos dedicar correspondientemente menos tiempo a las pruebas y la estabilización sin introducir ningún defecto nuevo.

Entonces, en mi experiencia, las pruebas de aceptación, especialmente cuando se realizan muy temprano en un proyecto o sprint, y cuando se mantienen bien con los criterios de aceptación escritos por el Propietario del producto, son una de las mejores inversiones que puede hacer. A diferencia del TDD tradicional, que otras personas señalan correctamente se centra más en la creación de código comprobable que en el código libre de defectos : ATDD realmente ayuda a detectar defectos mucho más rápido; es el equivalente organizacional de tener un ejército de probadores haciendo una prueba de regresión completa todos los días, pero mucho más barata.

¿ATDD lo ayudará en proyectos a más largo plazo realizados en RUP o (ugh) estilo Cascada, proyectos que duran 3 meses o más? Creo que el jurado todavía está en eso. En mi experiencia, los riesgos más grandes y más feos en proyectos de larga duración son plazos poco realistas y requisitos cambiantes. Los plazos poco realistas harán que las personas tomen atajos, incluidos los atajos de prueba, y los cambios significativos en los requisitos probablemente invaliden una gran cantidad de pruebas, lo que requerirá que se reescriban y posiblemente inflen la sobrecarga de la implementación.

Estoy bastante seguro de que ATDD tiene una recompensa fantástica para los modelos Agile, o para los equipos que no son oficialmente Agile pero tienen calendarios de lanzamiento muy frecuentes. Nunca lo he probado en un proyecto a largo plazo, principalmente porque nunca he estado o incluso he oído hablar de una organización dispuesta a intentarlo en ese tipo de proyecto, así que inserte aquí el descargo de responsabilidad estándar. YMMV y todo eso.

PD En nuestro caso, no se requiere un esfuerzo adicional del "cliente", pero tenemos un propietario de producto dedicado y a tiempo completo que realmente escribe los criterios de aceptación. Si está en el negocio de "consultoría", sospecho que podría ser mucho más difícil lograr que los usuarios finales escriban criterios de aceptación útiles. Un propietario de producto / gerente de producto parece un elemento bastante esencial para hacer ATDD y, aunque una vez más solo puedo hablar desde mi propia experiencia, nunca he oído hablar de ATDD que se practique con éxito sin alguien para cumplir ese papel.

Aaronaught
fuente
Esto es muy útil, gracias. No se me ocurrió que ATTD podría cambiar el carácter del esfuerzo de TDD, pero tiene sentido, especialmente cuando escuchas sobre personas que son capaces de producir software bien escrito, relativamente libre de errores a tiempo y dentro del presupuesto sin necesariamente utilizando pruebas unitarias extensivamente.
Robert Harvey
@RobertHarvey: Debo aclarar que todavía creamos pruebas unitarias, pero no como parte de un proceso TDD. Típicamente, las pruebas de aceptación vienen primero o en paralelo con el desarrollo inicial, luego el código completo, luego las pruebas unitarias y la refactorización. A veces he pensado que TDD ayudaría a ciertos desarrolladores a escribir un mejor código, pero no puedo respaldar eso (todavía). Aunque puedo hablar por mí mismo, a menudo encuentro muchos errores y fallas de diseño en mi propio código simplemente durante el proceso de escribir las pruebas unitarias.
Aaronaught
1

Requerimientos de recursos

¿Cuál es, en su experiencia, el efecto general sobre los requisitos de recursos para completar un proyecto de software bajo TDD, en oposición a las metodologías de desarrollo más "tradicionales"?

En mi experiencia, el costo de requerir pruebas iniciales se mitiga de inmediato definiendo un criterio de aceptación claro por adelantado y luego escribiendo a la prueba. No solo se mitiga el costo de las pruebas iniciales, también he encontrado que generalmente acelera el desarrollo general. Aunque esas mejoras de velocidad pueden ser eliminadas por una definición deficiente del proyecto o cambios en los requisitos. Sin embargo, todavía podemos responder bastante bien a ese tipo de cambios sin un impacto severo. ATDD también reduce significativamente el esfuerzo del desarrollador para verificar el comportamiento correcto del sistema a través de su conjunto de pruebas automatizadas en los siguientes casos:

  • grandes refactores
  • actualizaciones de plataforma / paquete
  • migración de plataforma
  • actualizaciones de la cadena de herramientas

Esto supone un equipo que esté familiarizado con el proceso y las prácticas involucradas.

Involucramiento del cliente

¿Cuánto más esfuerzo se requiere del cliente?

Tienen que estar mucho más involucrados de manera continua. He visto una gran reducción en la inversión de tiempo inicial, pero una demanda mucho mayor en curso. No he medido, pero estoy bastante seguro de que es una inversión de tiempo más grande para el cliente.

Sin embargo, descubrí que la relación con el cliente mejora enormemente después de 5 o más demostraciones donde ven que su software toma forma lentamente. El compromiso de tiempo del cliente disminuye algo con el tiempo a medida que se desarrolla una relación, todos se acostumbran al proceso y las expectativas involucradas.

Estimacion del proyecto

Me imagino que las estimaciones de tiempo serían muy vagas en un proceso iterativo de TDD al comienzo de un proyecto TDD (ya que no existe un Plan de Desarrollo de Software).

He descubierto que, por lo general, es una cuestión de qué tan bien definida está la solicitud y si los líderes técnicos pueden sacar el proyecto (incluida la estimación de la tarjeta). Suponiendo que el proyecto esté bien organizado y tenga un promedio de velocidad razonable y una desviación estándar, hemos descubierto que es fácil obtener una estimación decente. Obviamente, cuanto más grande es el proyecto, mayor es la incertidumbre, por lo que generalmente divido un proyecto grande en un proyecto pequeño con la promesa de continuar más tarde. Esto es mucho más fácil de hacer una vez que haya establecido una relación con el cliente.

Por ejemplo:

Los "sprints" de mi equipo duran una semana y tenemos un promedio de carrera y estándar. desviación de las últimas 14 semanas. Si el proyecto es de 120 puntos, tenemos una media de 25 y una estándar. la desviación de 6 y luego estimar la finalización de un proyecto es:

Project Total / (Mean Velocity - (2 * Std. Deviation) = 95% Time Estimate
120           / (25            - (2 * 6             ) = 9.2 weeks

Usamos el 2 Std. Regla de desviación para nuestra estimación de confianza del 95%. En la práctica, generalmente completamos el proyecto bajo el primer estándar. desviación, pero por encima de nuestra media. Esto generalmente se debe a refinamientos, cambios, etc.

dietbuddha
fuente
Básicamente, lo que está diciendo es que TDD mejora el esfuerzo de desarrollo al alentar a las partes interesadas a hacer las cosas que deberían hacer de todos modos, como proporcionar requisitos claros y accionables y criterios de aceptación.
Robert Harvey
1
Bueno, no solo eso. A medida que avanza el proyecto, la mayor participación permite una mejor conversación entre los desarrolladores y las partes interesadas. Permite cosas como el desarrollo que ofrece alternativas menos costosas a medida que su comprensión de lo que quiere la parte interesada se refina aún más. Permite a las partes interesadas cambiar los requisitos antes cuando se dan cuenta de que faltan cosas o no funcionarán sin una respuesta tan antagónica del desarrollador; y sin muchas de las expectativas irracionales que generalmente provienen de los interesados.
dietbuddha
-1

requerir pruebas por adelantado parece que requeriría más horas de desarrollador para lograrlo. ¿Cuánto aumenta el esfuerzo de desarrollo, o en realidad disminuye debido a la eliminación inicial de errores?

Esto en realidad no es cierto. Si sus desarrolladores están escribiendo pruebas unitarias (y deberían hacerlo), entonces el tiempo debería ser aproximadamente el mismo, o mejor. Dije mejor, ya que su código se probará por completo y tendrán que escribir solo el código para cumplir con los requisitos.

El problema con los desarrolladores es que tienden a implementar incluso cosas que no son necesarias para que el software sea lo más genérico posible.

¿Cuánto más esfuerzo se requiere del cliente? ¿Tienen que cambiar la forma en que se relacionan con el proyecto, especialmente si están acostumbrados a grandes diseños desde el principio? ¿El número de horas requeridas por el cliente en general aumenta o realmente disminuye?

Eso no debería importar. Quien haga los requisitos debe hacerlo lo mejor posible.

Si realiza una forma ágil de desarrollo, eso no significa un gran diseño por adelantado. Pero, cuanto mejor se cumplan los requisitos, la arquitectura y el diseño, la calidad del código aumentará y el tiempo para finalizar el software disminuirá.

Por lo tanto, si les gusta hacer BDUF, que lo hagan. Te hará la vida más fácil como desarrollador.

BЈовић
fuente
1
Según tengo entendido, TDD y BDUF generalmente no son compatibles entre sí.
Robert Harvey
3
BDUF generalmente no es compatible con ninguna buena práctica de gestión del desarrollo. Pero sería posible hacer un proyecto BDUF de forma TDD. TDD es una técnica para crear software de mejor calidad, mientras que BDUF es una técnica para la obtención de requisitos. Una mala técnica, pero una técnica no obstante.
Stephen
@RobertHarvey Correcto, pero si quieren hacer BDUF, es su elección. Si realmente está haciendo ágil, entonces es libre de mejorar su diseño y aún hacer TDD.
Bћовић
entonces usted dice que si escribo prueba unitaria, mi código se probará por completo y si todas las pruebas pasan, eso por supuesto significa que el software está libre de errores (o al menos mejor). Por lo tanto, solo necesito probar todos los métodos de mi software, por ejemplo, "function testSqr () {int a = 3; ClaimTrue (mySqr (a) == 9);} function mySqr (int a) {return 9;}"
Dainius
@Dainius No, lee de nuevo. La cobertura del 100% del código no está libre de errores. Sí, necesita probar la unidad en cada método. Por supuesto, el acceso a la base de datos de prueba de unidad, GUI, etc. no tiene sentido. Las pruebas unitarias no son para esos.
Bћовић