¿Cómo hacer que los programadores junior escriban pruebas?[cerrado]

https://stackoverflow.com/questions/7252

08-06-2019
|

Pregunta

Tenemos un programador junior que simplemente no escribe suficientes pruebas.
Tengo que regañarlo cada dos horas: "¿Has escrito exámenes?"
Hemos probado:

Mostrando que el diseño se vuelve más simple.
Mostrarlo previene defectos
Hacer que sea una cuestión de ego decir que sólo los malos programadores no lo hacen.
Este fin de semana 2 miembros del equipo tuvieron que venir a trabajar porque su código tenía una referencia NULL y no lo probó.

Mi trabajo requiere código estable de alta calidad y, por lo general, todos lo "entienden" y no hay necesidad de realizar pruebas.Sabemos que podemos obligarlo a escribir pruebas, pero todos sabemos que las pruebas útiles son aquellas que se escriben cuando estás interesado.

¿Conoces más motivaciones?

Solución

Este es uno de las cosas mas dificiles hacer.Lograr que tu gente Consíguelo.

A veces, una de las mejores maneras de ayudar a los programadores de nivel junior a "entenderlo" y aprender las técnicas correctas de los mayores es hacer un poco de programación en pareja.

Prueba esto:En un próximo proyecto, empareje al joven con usted u otro programador senior.Deben trabajar juntos, turnándose para "conducir" (ser el que escribe en el teclado) y "entrenar" (mirar por encima del hombro del conductor y señalar sugerencias, errores, etc. a medida que avanzan).Puede parecer un desperdicio de recursos, pero encontrarás:

Que estos chicos juntos pueden producir código bastante rápido y de mayor calidad.
Si su chico junior aprende lo suficiente como para "entenderlo" con un chico senior dirigiéndolo por el camino correcto (por ejemplo,"Bien, antes de continuar, escribamos una prueba para esta función"). Valdrá la pena los recursos que le dedique.

Tal vez también haga que alguien en su grupo dé la Pruebas unitarias 101 presentación de Kate Rhodes, creo que es una excelente manera de entusiasmar a la gente con las pruebas, si se realizan bien.

Otra cosa que puedes hacer es que tu Jr.Los desarrolladores practican el Kata del juego de bolos lo que les ayudará a aprender el desarrollo basado en pruebas.Está en java, pero se puede adaptar fácilmente a cualquier idioma.

Otros consejos

Realice una revisión del código antes de cada confirmación (incluso si es un "Cambié el nombre de esta variable" de 1 minuto) y, como parte de la revisión del código, revise las pruebas unitarias.

No apruebe el compromiso hasta que las pruebas estén realizadas.

(Además, si su trabajo no fue probado, ¿por qué estaba en una versión de producción en primer lugar?Si no está probado, no lo dejes entrar, así no tendrás que trabajar los fines de semana)

Por mi parte, comencé a insistir en que cada error que encuentre y solucione se exprese como una prueba:

"Hmmm, eso no está bien..."
encontrar posible problema
Escribe una prueba, muestra que el código falla.
Arreglar el problema
Mostrar que el nuevo código pasa
Bucle si el problema original persiste

Intento hacer esto incluso mientras hago cosas, y termino aproximadamente al mismo tiempo, solo que con un conjunto de pruebas parcial ya implementado.

(No vivo en un entorno de programación comercial y, a menudo, soy el único programador que trabaja en un proyecto en particular).

Imagina que soy un programador simulado, llamado...Marco.Imagínese que me gradué de la escuela no hace mucho y nunca tuve que escribir exámenes.Imagínese que trabajo en una empresa que realmente no exige ni exige esto.¿DE ACUERDO?¡bien!Ahora imagine que la empresa está cambiando al uso de pruebas y está tratando de alinearme con esto.Daré una reacción algo sarcástica a los elementos mencionados hasta ahora, como si no hubiera investigado al respecto.

Comencemos con el creador:

Mostrando que el diseño se vuelve más simple.

¿Cómo escribir más puede simplificar las cosas?Ahora tendría que estar atento a cómo conseguir más casos, etc.Esto lo hace más complicado si me preguntas.Dame detalles sólidos.

Mostrarlo previene defectos.

Yo sé eso.Por eso se llaman pruebas.Mi código es bueno y lo verifiqué en busca de problemas, por lo que no veo en qué ayudarían esas pruebas.

Convirtiéndolo en una cuestión de ego, decir que sólo los malos programadores no lo hacen.

Ohh, entonces crees que soy un mal programador solo porque no hago tantas pruebas usadas.Me siento insultado y realmente molesto contigo.Prefiero tener ayuda y apoyo que dichos.

@estándar de justin:Al comenzar una nueva propuesta, empareje al joven con usted u otro programador senior.

Ohh, esto es tan importante que se gastarán recursos para asegurarme de que vea cómo se hacen las cosas y de que alguien me ayude en cómo se hacen las cosas.Esto es útil y quizás empiece a hacerlo más.

@estándar de justin:Leer Pruebas unitarias 101 Presentación de Kate Rhodes.

Ahh, esa fue una presentación interesante y me hizo pensar en realizar pruebas.Insistió en algunos puntos que debería considerar y podría haber influido un poco en mis puntos de vista.

Me encantaría ver artículos más interesantes y otras herramientas que me ayuden a pensar que esta es la forma correcta de hacer las cosas.

@Dominic Cooney:Dedique algo de tiempo y comparta técnicas de prueba.

Ahh, esto me ayuda a comprender lo que se espera de mí en cuanto a técnicas y añade más elementos a mi bolsa de conocimientos que podría utilizar nuevamente.

@Dominic Cooney:Responde preguntas, ejemplos y libros.

Tener una persona (personas) de contacto para responder las preguntas es útil, podría hacer que sea más probable que lo intente.Los buenos ejemplos son fantásticos y me dan algo a lo que aspirar y algo a lo que buscar referencias.Los libros que son relevantes directamente para esto son una gran referencia.

@Adam Hayle:Revisión sorpresa.

Dime, surgió algo para lo que no estoy preparado en absoluto.Me siento incómodo con esto, pero haré lo mejor que pueda.Ahora estaré asustado y ligeramente aprensivo de que esto vuelva a ocurrir, gracias.Sin embargo, la táctica del miedo podría haber funcionado, pero tiene un coste.Sin embargo, si nada más funciona, este podría ser el empujón que se necesita.

@Rytmis:Los elementos sólo se consideran terminados cuando tienen casos de prueba.

Oh, interesante.Veo que realmente tengo que hacer esto ahora; de lo contrario, no completaré nada.Esto tiene sentido.

@jmorris:Deshacerse / Sacrificio.

miradas, miradas, miradas - Existe la posibilidad de que aprenda y, con apoyo y asistencia, pueda convertirme en una parte muy importante y funcional de los equipos.Esta es una de mis desventajas ahora, pero no lo será por mucho tiempo.Sin embargo, si simplemente no lo consigo, entiendo que iré.Creo que lo conseguiré.

Al final, el apoyo de mi equipo jugará un papel importante en todo esto.Siempre es bienvenido que una persona se tome su tiempo para ayudarme y enseñarme a adoptar buenos hábitos.Luego, tener una buena red de apoyo sería fantástico.Siempre sería apreciado que alguien viniera unas cuantas veces después y repasara algún código para ver cómo fluye todo, no en una revisión per se, sino más bien como una visita amistosa.

Razonamiento, Preparación, Enseñanza, Seguimiento, Apoyo.

He notado que muchos programadores ven el valor de las pruebas en un nivel racional.Si has escuchado cosas como "Sí, sé que debería probar esto, pero realmente necesito hacerlo rápidamente", entonces sabes a qué me refiero.Sin embargo, a nivel emocional, sienten que logran hacer algo sólo cuando escriben el código real.

El objetivo, entonces, debería ser hacerles entender de alguna manera que las pruebas son, de hecho, solo manera de medir cuando algo está "hecho", y así darles la motivación intrínseca para escribir pruebas.

Pero me temo que es mucho más difícil de lo que debería ser.Escuchará muchas excusas como "Tengo mucha prisa, reescribiré/refactorizaré esto más tarde y luego agregaré las pruebas" y, por supuesto, el seguimiento nunca ocurre porque, sorprendentemente, 're igual de ocupado la próxima semana.

Esto es lo que haría:

Primera vez..."Vamos a hacer este proyecto en conjunto.Voy a escribir las pruebas y tú escribirás el código.Presta atención a cómo escribo las pruebas, porque así es como hacemos las cosas aquí y eso es lo que espero de ti".
Siguiendo esto..."¿Terminaste?¡Excelente!Primero, veamos las pruebas que impulsan su desarrollo.Ah, ¿no hay pruebas?Avíseme cuando esté hecho y reprogramaremos el análisis de su código.Si necesitas ayuda para formular las pruebas házmelo saber y te ayudaré."

Como programador junior, todavía estoy intentando adquirir el hábito de escribir pruebas.Obviamente no es fácil adquirir nuevos hábitos, pero pensando en qué haría que esto funcione para mí, tengo que hacer +1 en los comentarios sobre revisiones de código y programación de coaching/pareja.

También puede valer la pena enfatizar el propósito a largo plazo de las pruebas:garantizar que lo que funcionó ayer siga funcionando hoy, la semana que viene y el mes que viene.Solo digo eso porque al hojear las respuestas no vi que se mencionara.

Al realizar revisiones de código (si decide hacerlo), asegúrese de que su joven desarrollador sepa que no se trata de menospreciarlo, sino de mejorando el código. Porque de esa manera es menos probable que su confianza se dañe.Y eso es importante.Por otro lado, también lo es saber lo poco que sabes.

Por supuesto, realmente no sé nada.Pero espero que las palabras hayan sido útiles.

Editar:[estándar de justin]

No te menosprecies, lo que tienes que decir es bastante acertado.

En cuanto a su punto sobre las revisiones de código:lo que encontrará es que no solo el desarrollador junior aprenderá en el proceso, sino también los revisores.Todos los participantes en una revisión de código aprenden si lo convierte en un proceso colaborativo.

Francamente, si tienes que poner eso Si te esfuerzas mucho en lograr que haga algo, es posible que tengas que aceptar la idea de que tal vez simplemente no sea una buena opción para el equipo y que deba irse.Ahora bien, esto no significa necesariamente despedirlo...puede significar encontrar otro lugar en la empresa donde sus habilidades sean más adecuadas.Pero si no hay otro lugar... ya sabes qué hacer.

Supongo que también es un empleado bastante nuevo (<1 año) y probablemente acaba de terminar la escuela... en cuyo caso es posible que no esté acostumbrado a cómo funcionan las cosas en un entorno corporativo.Cosas como esas que la mayoría de nosotros podríamos hacer en la universidad.

Si este es el caso, una cosa que he encontrado funciona es tener una especie de "revisión sorpresa de nuevo alquiler". No importa si nunca lo has hecho antes ... él no lo sabrá.Simplemente siéntese y dígale que va a repasar su desempeño y mostrarle algunos números reales... tome su hoja de revisión normal (tiene un proceso de revisión formal, ¿verdad?) y cambie el encabezado si lo desea para que parezca funcionario y mostrarle su posición.Si le demuestra en un ambiente muy formal que no hacer pruebas está afectando negativamente su calificación de desempeño en lugar de simplemente "regañarlo" al respecto, es de esperar que entienda el punto.Tienes que demostrarle que sus acciones realmente le afectarán, ya sea en términos salariales o no.

Lo sé, quizás quieras evitar hacer esto porque no es oficial...pero creo que estás dentro de lo razonable para hacerlo y probablemente será mucho más barato que tener que despedirlo y reclutar a alguien nuevo.

Él ya está haciendo esto.En realidad.Simplemente no lo escribe.¿No convencido?Mírelo recorrer el ciclo de desarrollo estándar:

Escribe un fragmento de código
compilarlo
Corre a ver que hace
Escribe el siguiente fragmento de código.

El paso número 3 es la prueba.Él ya hace pruebas, simplemente las hace manualmente.Hazle esta pregunta:"¿Cómo sabes mañana que el código de hoy todavía funciona?" Él responderá:"¡Es una cantidad tan pequeña de código!"

Preguntar:"¿Qué tal la próxima semana?"

Cuando no tenga respuesta, pregúntele:"¿Cómo le gustaría que su programa le dijera cuando un cambio rompe algo que funcionó ayer?"

De eso se tratan las pruebas unitarias automáticas.

Como programador junior, pensé que revelaría cómo fue cuando me encontré en una situación similar a la de su desarrollador junior.

Cuando salí de la universidad por primera vez, descubrí que me había desequipado gravemente para lidiar con el mundo real.Sí, conocía algunos conceptos básicos de JAVA y algo de filosofía (no preguntes), pero eso fue todo.Cuando conseguí mi trabajo por primera vez fue un poco desalentador, por decir lo menos.Déjame decirte que probablemente era uno de los vaqueros más grandes que existen, crearía un pequeño algoritmo/corrección de errores sin comentarios/pruebas/documentación y lo enviaría por la puerta.

Tuve la suerte de estar bajo la supervisión de una persona amable y muy programador senior paciente.Por suerte para mí, decidió sentarse conmigo y pasar entre 1 y 2 semanas revisando juntos mi código, muy pirateado.Él me explicaba dónde me había equivocado, los puntos más finos de c y los punteros (¡eso me confundió!).Logramos escribir una clase/módulo bastante decente en aproximadamente una semana.Todo lo que puedo decir es que si el desarrollador senior no hubiera invertido el tiempo para ayudarme en el camino correcto, probablemente no habría durado mucho.

Afortunadamente, dentro de 2 años, espero que algunos de mis colegas incluso me consideren un programador promedio.

Llévate puntos a casa

La mayoría de las universidades son muy malas a la hora de preparar a los estudiantes para el mundo real.
La programación emparejada realmente me ayudó.Eso no quiere decir que ayude a todos, pero funcionó para mí.

Asígnalos a proyectos que no requieran "código estable de alta calidad" si eso es lo que te preocupa y deja que jr.el desarrollador falla.Haga que sean ellos quienes "vengan el fin de semana" para corregir sus errores.Almuerce mucho y hable sobre prácticas de desarrollo de software (no conferencias, sino debates).Con el tiempo adquirirán y desarrollarán las mejores prácticas para realizar las tareas que se les asignen.

Quién sabe, es posible que incluso se les ocurra algo mejor que las técnicas que utiliza actualmente su equipo.

Si el programador junior, o cualquier otra persona, no ve el valor de las pruebas, entonces será difícil lograr que lo hagan... punto.

Habría hecho que el programador junior sacrificara su fin de semana para corregir el error.Sus acciones (o la falta de ellas) no lo afectan directamente.Además, deje en claro que no verá avances ni aumentos salariales si no mejora sus habilidades en las pruebas.

Al final, incluso con toda su ayuda, aliento y tutoría, es posible que él no sea apto para su equipo, así que déjelo ir y busque a alguien que sí lo entienda.

Apoyo el comentario de RodeoClown sobre el código que revisa cada confirmación.Una vez que lo haya hecho varias veces, adquirirá el hábito de probar cosas.

Sin embargo, no sé si es necesario bloquear confirmaciones como esa.En mi lugar de trabajo, todos tienen compromisos gratuitos para todo y todos los mensajes de compromiso SVN (con diferencias) se envían por correo electrónico al equipo.

Nota:tú en realidad quiero el Complemento de diferencias de colores de Thunderbird si planeas hacer esto.

Mi jefe o yo (los dos codificadores 'senior') terminaremos leyendo las confirmaciones, y si hay algo como "olvidaste agregar pruebas unitarias", simplemente enviamos un correo electrónico o vamos a charlar con la persona, explicándole por qué necesitaba pruebas unitarias o lo que sea.Se anima a todos los demás a leer también las confirmaciones, ya que es una excelente manera de ver qué está pasando, pero los desarrolladores junior no comentan mucho.

Puedes ayudar a alentar a las personas a que adquieran el hábito de esto diciendo periódicamente cosas como "Oye, Bob, ¿viste el compromiso que hice esta mañana? Encontré este ingenioso truco en el que puedes hacer bla, bla, lo que sea, lee el compromiso y verás". ¡cómo funciona!"

NÓTESE BIEN:Tenemos 2 desarrolladores 'senior' y 3 junior.Es posible que esto no se escale o que necesite ajustar un poco el proceso con más desarrolladores.

Haga que la cobertura del código forme parte de las revisiones.
Haga que "escribir una prueba que exponga el error" sea un requisito previo para corregir un error.
Requiere un cierto nivel de cobertura antes de que se pueda registrar el código.
Encuentre un buen libro sobre desarrollo basado en pruebas y utilícelo para mostrar cómo las pruebas primero pueden acelerar el desarrollo.

Mucha psicología y técnicas útiles de "tutoría" pero, sinceramente, esto se reduce a "escribir exámenes si todavía quieres tener un trabajo mañana".

Puedes expresarlo en los términos que creas apropiados, duros o suaves, no importa.Pero el hecho es que a los programadores no se les paga para simplemente crear código y verificarlo: se les paga para armar el código cuidadosamente, luego armar pruebas, luego probar su código y LUEGO verificar todo.(Al menos eso es lo que parece, según su descripción).

Por lo tanto, si alguien se va a negar a hacer su trabajo, explíquele que puede quedarse en casa mañana y contratará a alguien que HARÁ el trabajo.

Nuevamente, puedes hacer todo esto suavemente, si crees que es necesario, pero mucha gente sólo necesita una gran bofetada. La vida en el mundo real, y les estarías haciendo un favor dándoselo.

Buena suerte.

Cambie la descripción de su trabajo por un tiempo para que únicamente escriba pruebas y las mantenga.He oído que muchas empresas hacen esto para personas nuevas e inexpertas durante un tiempo cuando empiezan.

Además, lanza un desafío mientras esté en ese rol:Escriba pruebas que a) fallen en el código actual a) cumplan con los requisitos del software.Con suerte, esto le permitirá crear algunas pruebas sólidas y exhaustivas (mejorando el proyecto) y mejorar su redacción de pruebas para cuando se reintegre al desarrollo central.

editar> cumplir con los requisitos del software, lo que significa que no solo está escribiendo pruebas para descifrar el código intencionalmente cuando el código nunca tuvo la intención o la necesidad de tener en cuenta ese caso de prueba.

Si su colega carece de experiencia en la redacción de exámenes, tal vez tenga dificultades para realizar pruebas más allá de situaciones simples, y eso se manifiesta como pruebas inadecuadas.Esto es lo que yo probaría:

Dedique algo de tiempo y comparta técnicas de prueba, como inyección de dependencia, búsqueda de casos extremos, etc., con su colega.
Ofrézcase a responder preguntas sobre las pruebas.
Realice revisiones de código de pruebas por un tiempo.Pídale a su colega que revise los cambios suyos que sean ejemplares de buenas pruebas.Mire sus comentarios para ver si realmente están leyendo y comprendiendo su código de prueba.
Si hay libros que encajan particularmente bien con la filosofía de pruebas de su equipo, entréguele una copia.Podría ser útil que los comentarios o las discusiones sobre la revisión del código hagan referencia al libro para que él o ella tenga un hilo para seguir.

No destacaría especialmente el factor vergüenza/culpabilidad.Vale la pena señalar que las pruebas son una buena práctica ampliamente adoptada y que redactar y mantener buenas pruebas es una cortesía profesional para que sus compañeros de equipo no necesiten pasar los fines de semana en el trabajo, pero no insistiría en esos puntos.

Si realmente necesita "ponerse duro", entonces instituya un sistema imparcial;A nadie le gusta sentirse señalado.Por ejemplo, su equipo podría requerir código para mantener un cierto nivel de cobertura de prueba (que se pueda jugar, pero al menos se pueda automatizar);requerir código nuevo para realizar pruebas;exigir a los revisores que consideren la calidad de las pruebas al realizar revisiones de código;etcétera.La institución de ese sistema debe surgir del consenso del equipo.Si modera la discusión con cuidado, podría descubrir otras razones subyacentes por las que las pruebas de su colega no son lo que esperaba.

Es responsabilidad de su mentor enseñarle.¿Qué tan bien le estás enseñando CÓMO realizar la prueba?¿Estás programando en pareja con él?Lo más probable es que el Junior no sepa CÓMO configurar una buena prueba para xyz.

Como estudiante recién salido de la escuela, conoce muchos conceptos.Alguna técnica.Alguna experiencia.Pero al final todo un Junior es POTENCIAL.En casi todas las funciones en las que trabajan, habrá algo nuevo que nunca antes habían hecho.Seguro que el Junior pudo haber hecho un patrón estatal simple para un proyecto en clase, abriendo y cerrando "puertas", pero nunca una aplicación de los patrones en el mundo real.

Él/ella será tan bueno como lo bien que le enseñes.Si hubieran podido "simplemente conseguirlo", ¿crees que habrían tomado una posición Junior en primer lugar?

En mi experiencia, los jóvenes son contratados y se les asigna casi la misma responsabilidad que los mayores, pero se les paga menos y luego se les ignora cuando empiezan a fallar.Perdóname si parezco amargado, es porque lo soy.

@jsmorris

Una vez, el desarrollador senior y el "arquitecto" me reprendieron a mí y a un evaluador (era mi primer trabajo después de la universidad) por correo electrónico por no quedarnos hasta tarde y terminar una tarea tan "fácil" la noche anterior.Habíamos estado en esto todo el día y lo dejamos a las 7 p. m., había estado peleando desde las 11 a. m. antes del almuerzo de ese día y había molestado a todos los miembros de nuestro equipo para que me ayudaran al menos dos veces.

Respondí y puse una copia del equipo con:"Estoy decepcionado de ti desde hace un mes.Nunca recibo ayuda del equipo.Estaré en la cafetería de enfrente si me necesitas.Lamento no haber podido depurar el método de 12 parámetros y 800 líneas del que depende casi todo".

Después de refrescarme en la cafetería durante una hora, regresé a la oficina, cogí mis cosas y me fui.A los pocos días me llamaron preguntando si iba a entrar, dije que sí pero que tenía una entrevista, tal vez mañana.

"¿Entonces vas a renunciar?"

En su repositorio de origen:use ganchos antes de cada confirmación (gancho de confirmación previa para SVN, por ejemplo)

En ese enlace, verifique la existencia de al menos un caso de uso para cada método.Utilice una convención para la organización de pruebas unitarias que pueda aplicar fácilmente mediante un enlace de confirmación previa.

En un servidor de integración, compile todo y verifique periódicamente la cobertura de la prueba utilizando una herramienta de cobertura de prueba.Si la cobertura de la prueba no es del 100 % para un código, bloquee cualquier confirmación del desarrollador.Debería enviarte el caso de prueba que cubra el 100% del código.

Sólo las comprobaciones automáticas pueden escalar bien en un proyecto.No se puede comprobar todo a mano.

El desarrollador debería tener un medio para comprobar si sus casos de prueba cubren el 100% del código.De esa manera, si no comete un código 100% probado, es culpa suya, no una falla de "ups, lo siento, lo olvidé".

Recordar :La gente nunca hace lo que esperas, siempre hace lo que inspeccionas.

En primer lugar, como señalan la mayoría de los encuestados aquí, si el tipo no ve el valor de las pruebas, no hay mucho que pueda hacer al respecto, y ya ha señalado que no puede despedirlo.Sin embargo, el fracaso no es una opción aquí, entonces, ¿qué pasa con las pocas cosas que poder ¿hacer?

Si su organización es lo suficientemente grande como para tener más de 6 desarrolladores, le recomiendo encarecidamente tener un departamento de Garantía de Calidad (incluso si es solo una persona para empezar).Idealmente, debería tener una proporción de 1 probador 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 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 deberían pasar al rol de control de calidad, ya que tienen la experiencia en el código. y (con suerte) hemos 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 generalmente no se trata de un error de sintaxis (esos se detectan en la compilación), sino de un error lógico, y la misma lógica está en funcionamiento cuando escriben el error. prueba como cuando escriben el código.No haga que la persona que desarrolló el código lo pruebe; encontrará menos errores que cualquier otra persona.

En su caso, si puede permitirse el esfuerzo laboral 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:Improving The Process", porque obviamente necesitará algo de capacitación en su nuevo rol.Si no le gusta, lo dejará y su problema seguirá 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 uno o dos probadores para hacer las pruebas ( Los estudiantes universitarios a menudo tienen períodos de práctica o "cooperativos", les encantaría la exposición y son baratos)

Nota al margen:Con el tiempo, 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 terminar el producto es un conflicto de intereses.

Si su organización tiene menos de 6 personas o no puede crear un nuevo equipo, le recomiendo la programación emparejada (PP).No soy un converso total de todas las técnicas de programación extrema, pero definitivamente creo en la programación emparejada.Sin embargo, ambos miembros del equipo de programación emparejado deben estar dedicados o simplemente no funciona.Tienen que seguir dos reglas:el inspector tiene que entender completamente lo que se está codificando en la pantalla o tiene que pedirle al codificador que se lo explique;el codificador sólo puede codificar lo que puede explicar: no se tolerará ningún tipo de "ya verás", "confía en mí" ni ningún gesto con la mano.

Sólo recomiendo PP si su equipo es capaz de hacerlo, porque, al igual que las pruebas, ninguna cantidad de aplausos 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 realizar revisiones de código vs.programación emparejada, el PP suele ganar.

Si PP no es para usted, entonces TDD es su mejor opción, pero sólo si se toma literalmente.El desarrollo basado en pruebas significa que usted escribe las pruebas PRIMERO, las ejecuta para demostrar que realmente fallan y luego escribe el código más simple para que funcione.La compensación es que ahora usted (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 tener una mayor probabilidad de cobertura de prueba y menos errores en el script.

Si todo lo demás falla, haga que los programadores equivalgan a un frasco de malas palabras: cada vez que el programador rompe la compilación, tiene 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ítalos :)

Bromas aparte, la mejor manera de hacer que su programador escriba pruebas es no dejarle programar.Si quieres un programador, contrata a un programador. Si quieres pruebas, contrata a un probador.Comencé como programador junior hace 12 años haciendo pruebas y se convirtió en mi carrera profesional y no lo cambiaría por nada.Un departamento de control de calidad sólido que esté adecuadamente nutrido y tenga el poder y el mandato para mejorar el software es tan valioso como los desarrolladores que escriben el software en primer lugar.

Esto puede ser un poco cruel, pero por la forma en que describe la situación, parece que necesita despedir a este tipo.O al menos dejarlo claro:negarse a seguir las prácticas de desarrollo de la casa (incluidas las pruebas de escritura) y Verificar un código defectuoso que otras personas tienen que limpiar eventualmente hará que te despidan.

La razón principal por la que los ingenieros/programadores junior no se toman mucho tiempo para diseñar y realizar scripts de prueba es porque la mayoría de las certificaciones de CS no lo requieren en gran medida, por lo que otras áreas de la ingeniería se cubren con más detalle en los programas universitarios, como los patrones de diseño.

En mi experiencia, la mejor manera de hacer que los profesionales jóvenes adquieran el hábito es hacerlo parte del proceso de forma explícita.Es decir, al estimar el tiempo que debería tomar una iteración, se debe incorporar a este tiempo estimado el tiempo de diseño, escritura y/o ejecución de los casos.

Finalmente, revisar el diseño del script de prueba debe ser parte de una revisión de diseño, y el código real debe revisarse en la revisión de código.Esto hace que el programador sea responsable de realizar pruebas adecuadas de cada línea de código que escribe, y que el ingeniero senior y sus pares sean responsables de proporcionar comentarios y orientación sobre el código y las pruebas escritas.

Según su comentario, "Mostrando que el diseño se vuelve más simple", supongo que ustedes practican TDD.Hacer una revisión del código a posteriori no funcionará.Lo importante de TDD es que es un diseño y no una filosofía de prueba.Si él no escribió las pruebas como parte del diseño, no obtendrá muchos beneficios al escribir pruebas después del hecho, especialmente de un desarrollador junior.Terminará perdiendo muchos casos de esquina y su código seguirá siendo malo.

Lo mejor que puedes hacer es tener un muy Pídale al paciente desarrollador senior que se siente con él y haga algo de programación en pareja.Y sigue así hasta que aprenda.O no aprende, en cuyo caso deberás reasignarlo a una tarea para la que sea más adecuado porque terminarás frustrando a tus verdaderos desarrolladores.

No todo el mundo tiene el mismo nivel de talento y/o motivación.Los equipos de desarrollo, incluso los ágiles, están formados por personas del "equipo A" y personas del "equipo B".Los miembros del A-Team son quienes diseñan la solución, escriben todo el código de producción no trivial y se comunican con los propietarios de la empresa: todo el trabajo que requiere pensar de forma innovadora.El B-Team se encarga de cosas como la gestión de la configuración, la escritura de scripts, la corrección de errores poco convincentes y el trabajo de mantenimiento: todo el trabajo que tiene procedimientos estrictos que tienen pequeñas consecuencias en caso de fallo.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow