En primer lugar, como la mayoría de los encuestados señalan aquí, si el chico no ve el valor de las pruebas, no hay mucho que puedas hacer al respecto y ya has señalado que no puedes despedirlo. Sin embargo, el fracaso no es una opción aquí, entonces, ¿qué pasa con las pocas cosas que puede hacer?
Si su organización es lo suficientemente grande como para tener más de 6 desarrolladores, le recomiendo encarecidamente tener un departamento de Control de calidad (incluso si es solo una persona para comenzar). Idealmente, debería tener una proporción de 1 evaluador por cada 3-5 desarrolladores. Lo que pasa con los programadores es ... son programadores, no probadores. Todavía tengo que entrevistar a un programador al que se le hayan enseñado formalmente las técnicas adecuadas de control de calidad.
La mayoría de las organizaciones cometen el error fatal de asignar los roles de prueba al nuevo empleado, la persona con la MENOR exposición a su código; idealmente, los desarrolladores senior deben pasar al rol de QA ya que tienen la experiencia en el código. y (con suerte) han desarrollado un sexto sentido para los olores del código y los puntos de falla que pueden surgir.
Además, el programador que cometió el error probablemente no encontrará el defecto porque normalmente no es un error de sintaxis (los que se recogen en la compilación), sino un error lógico, y la misma lógica está en funcionamiento cuando escriben el prueba como cuando escriben el código. No pida a la persona que desarrolló el código que pruebe ese código, encontrará menos errores que cualquier otra persona.
En su caso, si puede permitirse el esfuerzo de trabajo redirigido, convierta a este nuevo chico en el primer miembro de su equipo de control de calidad. Haga que lea "Pruebas de software en el mundo real: Mejorando el proceso", porque obviamente necesitará algo de capacitación en su nuevo rol. Si no le gusta, lo dejará y su problema aún estará resuelto.
Un enfoque un poco menos vengativo sería dejar que esta persona haga lo que se le da bien (supongo que esta persona fue contratada porque en realidad es competente en la parte de programación del trabajo) y contratar a uno o dos probadores para hacer las pruebas ( Los estudiantes universitarios a menudo tienen prácticas o términos "cooperativos", les encantaría la exposición y son baratos)
Nota al margen: Eventualmente, querrá que el equipo de control de calidad informe a un director de control de calidad, o al menos no a un gerente de desarrollo de software, porque hacer que el equipo de control de calidad informe al gerente, cuyo objetivo principal es hacer el producto, es un conflicto de interesar.
Si su organización tiene menos de 6, o no puede salirse con la suya creando un nuevo equipo, le recomiendo la programación emparejada (PP). No soy un converso total de todas las técnicas de programación extremas, pero definitivamente soy un creyente en la programación emparejada. Sin embargo, ambos miembros del equipo de programación emparejado tienen que estar dedicados, o simplemente no funciona. Deben seguir dos reglas: el inspector debe comprender completamente lo que se codifica en la pantalla o debe pedirle al codificador que se lo explique; el codificador sólo puede codificar lo que puede explicar: no se tolerará ningún "verás" o "confía en mí" o agitar las manos.
Solo recomiendo PP si su equipo es capaz de hacerlo, porque, al igual que las pruebas, ninguna cantidad de vítores o amenazas persuadirá a un par de introvertidos llenos de ego a trabajar juntos si no se sienten cómodos haciéndolo. Sin embargo, encuentro que entre la elección de escribir especificaciones funcionales detalladas y hacer revisiones de código frente a la programación emparejada, el PP generalmente gana.
Si PP no es para usted, entonces TDD es su mejor opción, pero solo si se toma literalmente. Test Driven Development significa que usted escribe las pruebas PRIMERO, ejecuta las pruebas para demostrar que realmente fallan y luego escribe el código más simple para que funcione. La compensación es que ahora (debería) tener una colección de miles de pruebas, que también es código, y es tan probable que contenga errores como el código de producción. Seré honesto, no soy un gran admirador de TDD, principalmente por esta razón, pero funciona para muchos desarrolladores que prefieren escribir scripts de prueba que documentos de casos de prueba; algunas pruebas son mejores que ninguna. Combine TDD con PP para una mejor probabilidad de cobertura de prueba y menos errores en el script.
Si todo lo demás falla, pida a los programadores la equivalencia de un frasco de juramentos: cada vez que el programador rompe la compilación, tienen que poner $ 20, $ 50, $ 100 (lo que sea moderadamente doloroso para su personal) en un frasco que va a su favorito ( registrado!) caridad. Hasta que paguen, evítelos :)
Dejando de lado las bromas, la mejor manera de hacer que su programador escriba pruebas es no dejar que programe. Si desea un programador, contrate a un programador: si desea pruebas, contrate a un probador. Comencé como programador junior hace 12 años haciendo pruebas, y se convirtió en mi trayectoria profesional, y no lo cambiaría por nada. Un departamento de control de calidad sólido que se nutre adecuadamente y se le da el poder y el mandato para mejorar el software es tan valioso como los desarrolladores que escriben el software en primer lugar.