¿Cómo convenció a su gerente para que le permitiera probar la unidad?

Por "uso", me refiero a que se me permita desarrollar, registrar el control de origen y mantener las pruebas unitarias a lo largo del tiempo, etc.

Las objeciones de gestión típicas son:

1. El cliente no pagó por las pruebas unitarias.
2. El proyecto no permite tiempo para pruebas unitarias.
3. ¿Deuda técnica? ¿Qué deuda técnica?

¿Conoces otras objeciones? ¿Cuáles fueron tus respuestas?

¡Gracias por adelantado!

Me encontré con este problema recientemente cuando un cliente estaba a bordo con nuestra metodología, pero la alta gerencia se enteró de que los desarrolladores pasaban su tiempo probando en lugar de desarrollar y estaban preocupados por esto, después de todo, ¡tenían personas de control de calidad para hacer las pruebas! Blogueé sobre cómo lo traté aquí:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Para resumir, comparé nuestras horas estimadas con las horas reales del proyecto y luego comparé nuestra tasa de defectos con la tasa de defectos de otros equipos. En nuestro caso, estos números se compararon favorablemente y no hubo más preocupaciones.

Mi conclusión basada en esta experiencia es:

... la mejor manera de convencer a cualquiera de que su enfoque para hacer algo es práctico y pragmático, es hacerlo y compararlo con otros enfoques. A la gente no le importa el dogma, o por qué crees que algo debería ser la mejor manera. Solo mostrando a las personas los números y midiendo la efectividad de su enfoque puede realmente demostrar que sus prácticas son efectivas.

En otros proyectos, hemos trabajado junto a desarrolladores de clientes que no crearon pruebas unitarias ni hicieron TDD y tuvimos que mantener pruebas que no funcionaban. Sin embargo, es muy fácil vender el enfoque TDD a esos desarrolladores de clientes cuando puedes decirles lo que han roto en el código antes de que lo sepan.

Entonces, en su caso, lo haría sigilosamente si fuera necesario (tal vez hay un área pequeña del código que puede comenzar a probar que cambia con frecuencia o de la que es responsable), pero realice un seguimiento de sus números : ¿cuál es el esfuerzo para crear tus pruebas? ¿Cuál es la tasa de defectos? ¿Cómo se compara esto con otros proyectos / miembros del equipo?

En mi opinión, nadie debería pedir permiso o disculparse por querer hacer su trabajo correctamente y cualquier desarrollador profesional debería intentar probar su código con pruebas automatizadas siempre que sea posible y práctico. Esperemos que sean ambas cosas en su caso. ¡Buena suerte!

Mostrar el retorno de la inversión (ROI)

Escribir pruebas automatizadas lleva tiempo. Una vez. Ejecutar pruebas automatizadas lleva cero tiempo, porque puede hacer otra cosa mientras se ejecutan.

Ejemplo: Probar manualmente la función X lleva 30 minutos. Escribir una prueba automatizada para ello llevaría 1 hora. Incluso si no tenemos errores, tendremos que probar la característica X diez veces durante el curso del proyecto a medida que se modifiquen sus capas y componentes dependientes. Entonces, automatizar la prueba de la función X nos ahorrará 4 horas durante la vida del proyecto.

En realidad, es cuando tiene un error que las pruebas automatizadas realmente dan sus frutos: primero, encuentran errores de manera temprana y económica, lo que ahorra tiempo y vergüenza. En segundo lugar, si tiene un error difícil y pasa por muchos ciclos de prueba de compilación de código para resolverlo, el tiempo ahorrado durante las pruebas manuales se suma extraordinariamente rápido.

Las empresas entienden ahorrar tiempo y dinero. Así es como venderlo.

Si ya los ha confrontado y no están de acuerdo con eso, pero no se siente cómodo escribiendo código sin ellos ... entonces no vuelva a preguntar. Solo escríbelos y no los registres.

La gerencia no va a contar líneas de código, pero verán que todos sus registros tienen tasas de aprobación más altas de QA (o clientes) y eventualmente preguntarán por qué ... entonces puede ser todo como "BAM! TDD ! "

No estás jugando con el proyecto, el proceso o la fuente ... así que no veo una razón negativa. Honestamente, no veo una razón por la cual sea diferente en el tiempo que ejecutar todas sus pruebas de resultados de ejecución manual + entrada + verificación.

1) El cliente no pagó por las pruebas unitarias

El cliente (pensó que) pagó por una solución de trabajo. Dependiendo de los contratos, la reparación de defectos puede ser rentable para su empresa. Si hay suficiente bloqueo. Por lo tanto, volver a pagar por una solución que funcione. TDD debería ayudar a ese objetivo.

2) El proyecto no permite tiempo para TDD

TDD no lleva más tiempo. Debería reducir la cantidad de código extraño o superfluo y enfocar la base del código en lo que hace pasar las pruebas. Todas las pruebas aprobadas, sujetas a la calidad y adecuación de la prueba, significa que el código está listo.

3) Deuda técnica? ¿Qué deuda técnica?

Tengo la impresión de que podría estar discutiendo para agregar retrospectivamente pruebas al código existente. Esta es una pesadilla de venta en el mejor de los casos y no brinda los beneficios que podría esperar. Sin embargo, agregar pruebas a medida que corrige errores debería ser aceptable y ayudar a largo plazo.

No recomiendo escribir las pruebas de todos modos, como lo sugirió Snorfus. Suena bien en teoría, pero las pruebas unitarias puedo y hacer cambios en el tiempo. A medida que cambian los requisitos, se agregan nuevas funciones y las pruebas unitarias deben actualizarse. Si está trabajando como parte de un equipo, las pruebas de su unidad quedarán desactualizadas a medida que otros agreguen funciones / correcciones.

Me dirijo a los puntos específicos que mencionó en lugar de plantear otros nuevos porque hay margen de maniobra para avanzar o comprender por qué está bloqueado.

Por cada cliente que enfrenta problemas de producción,

1. Escriba una prueba de Unidad y envíe un correo electrónico al gerente diciendo que ha agregado una prueba de Unidad para cubrir el escenario.

2. Y dígale que este problema no volverá a suceder en producción porque nuestra prueba de la unidad se ejecuta todas las noches y llegaremos a saber antes de que el código entre en producción observando el fallo de esta prueba de la unidad.

3. Dígale que si ya hubiéramos implementado esta prueba de la Unidad antes de que el código pasara a producción, este problema de producción nunca habría sucedido.

Haga esto de manera consistente y persistente y pronto estará convencido. A los gerentes no les gusta que el cliente enfrente problemas de producción y él comprará la idea de prueba de la Unidad. Buena suerte.