Cómo convencer a un patrocinador de proyecto de que todas las funciones de su código deben tener pruebas unitarias [cerrado]

Question

Las personas no técnicas en la mayoría de los casos no ven ningún valor en escribir pruebas unitarias.Solo quieren completar el código básico y no gastar dinero ni tiempo en cosas como pruebas unitarias.Más tarde, todos los días solo pedían que se corrigiera un error más.Los proyectos no cumplen con los plazos y todavía no ven valor en buenas pruebas automatizadas.

Answer 1

La mejor manera es no volverse tan técnico con personas "no técnicas".Simplemente inclúyelo en el tiempo de entrega sin entrar en detalles.

Por otro lado, parece que los plazos del proyecto no eran realistas para construirlo.

Answer 2

Yo solo escribió extensamente sobre este mismo tema.

Para resumir mis argumentos contra las quejas comunes:

La limpieza es invisible para los usuarios;Necesitamos agregar nuevas funciones.Los errores producidos constantemente por el código desordenado también son visibles para los usuarios.El tiempo dedicado a corregir esos errores podría haberse dedicado a agregar funciones.Cuanto más tiempo permanezcamos en deuda de calidad, más tiempo llevará agregar cada característica nueva.

No tenemos tiempo para limpiar.¿Prefieres dedicar tu tiempo a corregir los errores generados por el problema en lugar de solucionarlo?Eso es como cortar las malas hierbas todos los fines de semana en lugar de arrancarlas de raíz.Prevenir es dieciséis veces más valioso que curar.

Los desarrolladores se metieron en este lío;deberían salir de esto a su propio ritmo.Si los desarrolladores no hubieran lanzado lanzamientos tan rápido como lo hicieron, si no hubieran respondido tan rápidamente a los comentarios de los primeros usuarios, incluso cuando el producto se transformó en una bestia bastante diferente de su concepción original, no tendríamos nuestros clientes e ingresos actuales. .Estaríamos trabajando para otra empresa y no nos quejaríamos del software que construimos.

Atención directores ejecutivos:Señalar con el dedo impide la resolución.En su lugar, desafíe a sus desarrolladores a reducir los informes de errores.Esto se mide fácilmente, por lo que puede realizar un seguimiento del tiempo en comparación con los resultados.Recuerde, los desarrolladores prefieren implementar nuevas funciones antes que corregir errores, por lo que si están pidiendo tiempo para corregir errores, es algo grave.

Answer 3

Intente usar un análogo.Pregúnteles si les gustaría que sus hijos condujeran Volvos o coches Kit fabricados por algún tipo de la calle.La respuesta siempre debería ser el Volvo.Entonces pregunta ¿por qué?La respuesta es más confiable y segura.¿Cómo lo saben?La respuesta es probar.Todos los automóviles se someten a pruebas extremas y el coste lo refleja.Si quieren que el software sea lo más confiable posible, necesitan pruebas.(O se convierten en muñecos de prueba de choque)

Answer 4

Bueno, creo que el problema es que dices "todas las funciones".No todas las funciones necesitan pruebas unitarias, y algunos argumentarían que probar unitariamente funciones individuales es completamente incorrecto en muchos escenarios.

En su lugar, recomiendo realizar pruebas unitarias de "unidades de funcionalidad" reales.En lugar de escribir una única prueba para cada función, escriba una prueba para cada escenario o característica.Además de ahorrarle mucho tiempo y permitirle pasar las pruebas desapercibidas, a menudo es mucho más preciso porque literalmente prueba las funciones en la forma en que se utilizan.Con demasiada frecuencia, las pruebas unitarias función por función no prueban lo correcto o, peor aún, prueban simulacros.

Te recomiendo que evites el uso de simulacros en las pruebas a toda costa.El uso de un simulacro esencialmente invalida la prueba porque estás probando cómo funciona en circunstancias idealizadas en lugar de cómo funciona en el mundo real.

Un beneficio adicional es que también obtiene una mejor detección de códigos muertos.Cualquier código que no esté cubierto por una prueba de alto nivel probablemente no se esté utilizando y pueda eliminarse.Nunca subestimes el valor de eliminar el código muerto.

Answer 5

Vender pruebas unitarias completas después de que el desarrollo ya haya comenzado es muy duro.Incluso me atrevería a decir que muchas veces es imposible.Si no obtiene la aceptación de todas las partes interesadas del proyecto para realizar pruebas unitarias completas desde el principio, entonces debería estar contento con cualquier prueba unitaria que pueda realizar.

Answer 6

No lo haces.Las pruebas no deben ser algo que se escriba por separado, por lo que no es necesario tenerlas en cuenta en el cronograma más de lo que programaría específicamente "compilar" o "escribir el código".Cualquier tiempo dedicado a escribir las pruebas debe compensarse con el tiempo que le ahorran de todos modos.

Answer 7

Hazlo.Será más lento al principio a medida que escriba más código y piense primero en el problema.Pero rápidamente pasará a otros en el proyecto ya que tiene menos errores y su diseño es mejor.

Si diseña el sistema teniendo en cuenta las pruebas, será inherentemente un diseño más flexible que uno no comprobable.Entonces será más rápido agregar funciones en el futuro.

Answer 8

@Craig, también pensé en el análogo del automóvil, pero creo que la analogía se desmorona porque parece que ya hay pruebas presentes en el proyecto y es simplemente una cuestión de grado.En ese caso, la analogía del automóvil se convierte en "¿Le importa si la luz del techo del automóvil se prueba siempre y cuando se prueben los sistemas críticos (frenos, faros, transmisión, etc.)?".Como patrocinador de proyecto acosado que está viendo cómo el proyecto pasa de su fecha de finalización, realmente no me importa si la luz del techo se prueba o no.

Answer 9

Una buena manera de vender el valor de las pruebas unitarias es desde el punto de vista del soporte: si está utilizando un marco de pruebas unitarias que tiene un tiempo de ejecución que se puede implementar (nUnit es uno), puede tener un elemento de menú "Ejecutar pruebas unitarias". en su menú de ayuda.Esto puede ejecutar todas las pruebas unitarias y los resultados se pueden enviar al soporte técnico para ayudar a depurar los problemas del cliente.

Obviamente, hay muchas maneras de vender la mayor estabilidad, pero el soporte técnico es un costo de "dinero real" que la mayoría de los gerentes querrían reducir.