Para gerentes no técnicos he recurrido a una analogía de la construcción de una casa. ¿Construirían uno sin planos, simplemente tomando ladrillos de una pila y poniéndolos uno encima del otro con una idea vaga en la casa en mente? Si no, ¿por qué no aceptarán la documentación adecuada antes de la codificación, revisiones de diseño, etc.?
Para prueba de la unidad, podría intentar compararla con la calidad de las pruebas de los diversos componentes de la casa de forma individual antes de ponerlos juntos (ladrillos, cemento, puertas, ventanas, fontanería)
Para aquellos con cualquier agarre tecnología en absoluto, Mencione que entre el 30% y el 50% maneja las condiciones de error y la recuperación (en sistemas incrustados de misión crítica) y que simplemente no puede probar eso sin una prueba unitaria. Por ejemplo, si solo prueba la integración de blackbox, ¿cómo puede hacerlo? De una manera controlada y repetible; pruebe lo que sucede cuando el módulo A no puede asignar memoria en un punto determinado o expira profundamente en el módulo C cuando espera un mensaje de respuesta desde algún lugar, o una lectura de base de datos que normalmente tendrá éxito. Explique que al manipular los módulos de interfaz puede simular su comportamiento erróneo a voluntad.
Y, por supuesto, dibujo mi gráfico favorito con un símbolo $ en un eje y un reloj en el otro. Le gané a la gerencia todo esto en cada oportunidad para demostrar que el costo de obtener errores aumenta cuanto más tarde se descubren (cambiar una línea en una especificación de requisitos - 5 minutos; unos pocos parametros en un documento de diseño - horas; líneas de código (en la revisión del código o en la etapa de prueba de la unidad) - días: encontrar la aguja en un error del pajar y corregirla en la prueba del sistema - semanas).
No es solo una prueba de unidad; debe convencer a la gerencia y a sus compañeros desarrolladores de que la "carga innecesaria" de documentación, revisiones, pruebas ... s/w Procesos en general (y eso incluye aprender nuevas herramientas) ... en realidad ahorra tiempo en lugar de agregar tiempo a un proyecto. En otras palabras, lleva más tiempo y cuesta más equivocarse. Mida dos veces, corte una vez, etc.
Para la prueba unitaria, dígales acerca de continuous integration. Recomiendo encarecidamente a Jenkins, pero utiliza lo que sea que funcione para ti. Explique que una compilación normal, ya sea cada noche o con cada check-in, puede automáticamente extraer pruebas de unidad de su VCS y ejecutarlas, enviando correos electrónicos o alertando de otro código que rompió las pruebas existentes casi tan pronto como suceden.
Si nada de esto funciona, buscar un nuevo trabajo (si se encuentra en Singapur, o quiere ser, hablar conmigo ;-)
Como con todos persuasión - mostrar por qué lo que sugieres es en * su * inetrest. – Mawg