it-swarm-es.com

Pruebas subcontratadas por la empresa; ¿Cómo podemos alentar a los programadores a dejar de depender demasiado de los evaluadores?

Un amigo mío está trabajando en una empresa de 200 empleados. El negocio de la compañía no tiene nada que ver con TI, pero tienen un departamento de TI para trabajar, entre otros, en su sitio web, utilizado por los clientes.

El sitio web comenzó con una idea central de que los programadores tienen que probar la aplicación ellos mismos utilizando pruebas automatizadas. Sin embargo, rápidamente comenzó a ser problemático, ya que los programadores pasaban demasiado tiempo escribiendo pruebas funcionales con Selenium (y luego Cypress.io ) tratando de lidiar con interacciones complicadas, como arrastrar y soltar o cargar archivos, o tratar de descubrir por qué las pruebas fallan al azar. Durante un tiempo, más del 25% del tiempo se dedicó a esas pruebas; Además, la mayoría de los programadores estaban enojados por esas pruebas, ya que querían producir un valor real, no tratar de averiguar por qué las pruebas fallaban al azar.

Hace dos años, se decidió pagar a una empresa de Bulgaria para que realizara las pruebas funcionales de nivel de interfaz manualmente. Las cosas salieron bien, ya que tales pruebas fueron bastante económicas. En general, los programadores ofrecían funciones más rápido, con menos regresiones, y todos estaban contentos.

Sin embargo, con el tiempo, los programadores comenzaron a sentirse demasiado confiados. Escribirían menos integración o incluso pruebas unitarias, y a veces marcarían las características como hechas sin siquiera comprobar si funcionan en un navegador: dado que los evaluadores detectarán los errores, ¿por qué molestarse? Esto crea dos problemas: (1) lleva más tiempo resolver los problemas cuando los probadores los descubren hace unos días (en comparación con cuando los programadores los descubren en cuestión de minutos) y (2) el costo total de los probadores subcontratados Crece constantemente.

Recientemente, el líder del equipo intenta cambiar este comportamiento al:

  • Medir, por persona, cuántos boletos vuelven a abrir los evaluadores (y compartir los resultados con todo el equipo).

  • Felicitar a las personas que obtuvieron los mejores resultados, es decir, aquellos que tienen la menor cantidad de entradas que se vuelven a abrir.

  • Dedique tiempo a programar con los que obtuvieron el peor rendimiento, tratando de entender por qué son tan reacios a probar su código y mostrándoles que no es tan difícil.

  • Explicando que es mucho más rápido resolver un problema en este momento, que esperar varios días hasta que se pruebe la función.

  • Explicando que los probadores solo hacen pruebas del sistema, y ​​la falta de pruebas unitarias dificultan la localización exacta del problema.

Sin embargo, no funciona:

  • Las métricas no siempre son relevantes. Uno puede trabajar en un boleto poco claro o complejo que los probadores vuelven a abrir varias veces debido a los casos de Edge, y mientras tanto un colega puede trabajar en un boleto que es tan sencillo que no hay absolutamente ninguna posibilidad de introducir ninguna regresión.

  • Los programadores son reacios a probar el código, porque (1) lo encuentran aburrido, y porque (2) si no prueban el código, parece que ofrecen la función más rápido.

  • Tampoco ven por qué solucionar un problema días después de desarrollar una característica sería un problema. Entienden la teoría, pero no la sienten en la práctica. Además, creen que incluso si tomara un poco más de tiempo, todavía es más barato para la compañía pagar probadores subcontratados de bajo costo en lugar de pasar el tiempo de los programadores en las pruebas. Decirles repetidamente que este no es el caso no tiene ningún efecto.

  • En cuanto a las pruebas del sistema frente a las pruebas unitarias, los programadores responden que no pasan tanto tiempo buscando la ubicación exacta de un problema informado por un probador de todos modos (lo que parece ser realmente cierto).

¿Qué más se puede hacer para alentar a los programadores a dejar de confiar demasiado en los probadores?

49
Arseni Mourzenko

Me parece que hay una contradicción en la política aquí.

Por un lado, la empresa ha subcontratado las pruebas porque consume demasiado tiempo de los programadores y otros pueden hacerlo de manera más económica.

Ahora, se quejan de que los programadores confían en los probadores y deberían estar haciendo más pruebas por adelantado.

Puedo entender desde el punto de vista de la administración que se percibe que hay un medio feliz, pero en realidad los programadores no están realizando un análisis minucioso, caso por caso, de la cantidad de pruebas que realizan ellos mismos y cómo mucho lo subcontratan.

Intentar hacerlo consumiría demasiado tiempo y esfuerzo intelectual, y probablemente sin producir resultados precisos. ¿Cómo haría un programador para estimar cuántos errores tiene un código en particular y luego sopesar el beneficio económico de pasar su tiempo buscándolos en lugar de dejar que los probadores los busquen? Es un absurdo.

En cambio, los programadores siguen reglas generales. Anteriormente, la regla era probar exhaustivamente. Ahora la regla es ahorrar un valioso tiempo del programador, sacar más código de la puerta y dejar las pruebas a los evaluadores (que se cree que son diez centavos).

No es una respuesta buscar un medio feliz, porque en la práctica lo que sucederá es que los anal-retentivos volverán a pasar el 25% de su tiempo probando, y los vaqueros continuarán arrojando códigos de baja calidad por la puerta, y rasgos de personalidad como la conciencia y la atención al detalle (o la falta de ella) predominarán sobre el juicio. Si la gerencia trata de hostigar a ambos tipos para lograr que se ajusten más a un promedio que se percibe como económicamente ideal, ambos probablemente terminarán sintiéndose acosados.

También comentaría de pasada, que el 25% del tiempo que se dedicó a las pruebas para empezar, no me parece excesivo.

63
Steve

En pocas palabras: este es un problema cultural

Vengo del punto de vista de que los programadores competentes al menos escriben pruebas unitarias para las partes más complejas de su código. El problema no es que todos compartan mi punto de vista. Conozco personas que han estado desarrollando código más tiempo de lo que he estado vivo y también prueban su código, pero no necesariamente con pruebas automatizadas. Hay una serie de cosas en el desarrollo de software que son demasiado simples para probar, por lo que esas pruebas no tienen ningún valor real.

Dicho esto, hay diferentes niveles de prueba con diferentes porcentajes de fallas aleatorias que pueden suceder. Desde una perspectiva de gestión, debe comprender dónde gana valor.

  • Pruebas unitarias: verifique los detalles de implementación y el manejo de errores tan cerca de la lógica como sea posible.
  • Pruebas de integración: comprobar que las especificaciones del sistema funcionan correctamente
  • Pruebas de interfaz de usuario: compruebe que la aplicación se comporta de acuerdo con los requisitos

Como era de esperar, cuanto más te alejas de las unidades de código individuales, más frágiles se vuelven tus pruebas. Cuantas más piezas tenga que funcionen juntas, más posibilidades hay de que algo salga intermitentemente. Lo que eso significa es que cuanto más cerca de la prueba de unidad pueda detectar problemas, más confiables y valiosas serán esas pruebas.

Costo de automatización

La automatización cuesta tiempo. El tiempo cuesta dinero. Se tarda más en escribir pruebas automatizadas que en probar manualmente una función. Sin embargo, cada vez que se ejecuta una prueba automatizada, se ejecuta en una fracción del tiempo de la prueba manual. Desde el punto de vista de la administración, desea asegurarse de tener un buen retorno de su inversión. Recomiendo encarecidamente que el código de mayor riesgo, si se rompe la aplicación es inútil, debe tener pruebas automatizadas para garantizar que detecte regresiones (código roto) tan pronto como ocurran. Si las pruebas unitarias no pasan, el desarrollador no puede empujar su código.

En general, es útil tener algunas pautas y un medio para garantizar que el código de alto riesgo esté cubierto.

  • Las pruebas unitarias deben tener al menos 25% de cobertura. (Personalmente prefiero más alto, pero para un equipo sin pruebas unitarias, este es un buen lugar para comenzar)
  • Las pruebas unitarias y de integración deben priorizarse primero en el código de alto riesgo.
  • Definición de Hecho necesita tener uno o ambos requisitos:
    • Revisión por pares de código (las solicitudes de extracción son una excelente manera de organizarlas)
    • La cobertura de la prueba unitaria cumple con los criterios mínimos

Costo de la prueba manual

Las pruebas manuales cuestan tiempo. El tiempo cuesta dinero. Si bien es más rápido probar manualmente una función una vez, lleva la misma cantidad de tiempo probarla cada vez. Desea seguir probando características terminadas para protegerlo de las regresiones. Las regresiones son funcionalidades en su aplicación que solían funcionar y que ya no funcionan.

El costo oculto de las pruebas manuales es que los evaluadores son personas y, a veces, las personas se saltan las pruebas por accidente. Si pensabas que escribir pruebas automatizadas era tedioso, prueba probar las mismas funciones con todos los clics de botón una y otra vez.

Optimizando su inversión

Aquí es donde tanto la administración como el desarrollo deben estar en la misma página. Si la calidad es importante para la empresa, la empresa debe estar dispuesta a invertir en calidad. Si la calidad no es importante, simplemente elimine las pruebas. Sus usuarios se quejarán, y usted puede o no sentirse avergonzado por los problemas de los que se quejan. Dicho esto, si la aplicación es de misión crítica, entonces la calidad debería ser importante.

  • Automatizar las pruebas de código de alto riesgo
    • El riesgo puede ser alto debido a la complejidad de la solución.
    • El riesgo puede ser alto debido a la necesidad de la función.
    • El riesgo puede ser alto debido a la gran cantidad de dependencias del código
  • No escriba pruebas para el código que es demasiado simple para fallar (como getters y setters)
  • Pruebe manualmente cosas que son demasiado complicadas para probar automáticamente (como arrastrar/soltar)
  • Invierta en simplicidad
    • Un requisito por sí solo puede ser lo suficientemente simple, pero puede entrar en conflicto con otros requisitos.
    • Esté preparado para eliminar funciones para que la aplicación satisfaga las necesidades actuales.
  • Defina "hecho" para que quede claro y sin ambigüedades
    • Cuando el trabajo que debe hacerse no está claro, los desarrolladores y evaluadores tienen diferentes opiniones sobre lo que es correcto.
    • Unos minutos más en una reunión con tres personas pueden ahorrar días de trabajo y retrabajo debido a las diferentes definiciones de hecho.

Resumen

La cultura de la empresa se encuentra actualmente en una situación de no ganar. Los cambios culturales son más fáciles cuando la administración tiene la aceptación. También es más fácil cuando el equipo introduce disciplinas que los ayudan a ser más efectivos. Con ese fin, priorizaría Definir Hecho antes de priorizar cualquier cosa relacionada con la forma en que se realizan las pruebas.

Es genial que estés recopilando métricas. No es genial cómo se utilizan actualmente esas métricas. Una mejor manera es observar las tendencias en las métricas a medida que introduce más estructura en cómo su equipo desarrolla software. Por ejemplo, si se mejora el tiempo de finalización y el número de fallas en las pruebas se reduce porque pasa más tiempo definiendo lo que debe hacerse, entonces eso es una victoria. Si aumenta su cobertura de prueba automatizada al 50% y no ve ninguna mejora en el número de fallas de prueba, entonces tal vez el 25% sea lo suficientemente bueno.

El desarrollo de software es una actividad de equipo. Cuanto más trabajen juntos como equipo, mejor será la actitud de todos. Cuanto más esté configurado su equipo para el éxito, más experimentará su equipo.

33
Berin Loritsch

De acuerdo, todos compartimos el objetivo común de proteger y defender a los desarrolladores, pero hay algunas cosas en su pregunta que me hacen sentir un poco incómodo ...

Tampoco ven por qué solucionar un problema días después de desarrollar una característica sería un problema. Entienden la teoría, pero no la sienten en la práctica.

Lamento dar la noticia, pero los programadores experimentados sienten el valor de detectar un error al principio de la práctica .

En cuanto a las pruebas del sistema frente a las pruebas unitarias, los programadores responden que no pasan tanto tiempo buscando la ubicación exacta de un problema informado por un probador de todos modos (lo que parece ser realmente cierto).

Este es el libro de texto ¡charla defensiva (huele algo pasivo-agresivo). Y, por supuesto, es verdad ... hasta que lo pongas en perspectiva. Puede preguntar a los programadores ... ¿usan marcadores en sus navegadores? ¿Pagina de inicio un motor de búsqueda? ¿Utilizan alt + tab para cambiar entre aplicaciones/ventanas? Todas estas cosas son excusas lamentables de ganancias de productividad ... es decir, si las haces [~ # ~] una vez [~ # ~] . Cuando lo hace todo el tiempo , esos pocos segundos ganados se resumen fácilmente en innumerables días-hombre de productividad. ¿A sus programadores les lleva un minuto encontrar la fuente de un problema informado por el probador? Ese es el momento en que sintieron . El tiempo real incluye el tiempo del probador, el tiempo para preparar el informe/archivo del ticket, el tiempo potencialmente gastado en comunicar los detalles y el tiempo para cerrar el ticket/informarlo como resuelto. Y el tiempo es dinero, ¿verdad?

Piense en esto como olvidarse de comprar leche cuando vaya a comprar comida. Mientras estás EN la tienda, es 1 minuto de caminata. Cuando estás en casa, es exponencialmente más. Ahora, para ponerlo en perspectiva, así es como 1 minuto de tiempo sentido se traduce en ~ 30 minutos de problemas reales para todos los involucrados (aunque probablemente sea mucho más en realidad). Si la gerencia supiera que las pruebas adecuadas podrían ahorrarle a la compañía aproximadamente 30 veces el tiempo que ocasionalmente pasa dada la situación actual, ¿cómo se sentirían?

Además...

Durante un tiempo, más del 25% del tiempo se dedicó a esas pruebas; Además, la mayoría de los programadores se enojaron con esas pruebas, ya que querían producir un valor real, no tratar de averiguar por qué la prueba fallaría al azar.

Nuevamente, lamento dar la noticia, pero los programadores experimentados entienden que hay un valor real en las pruebas más el 25% del tiempo en realidad no es tan malo un porcentaje. ¡Las buenas pruebas valen su longitud en oro! Además, las pruebas no fallan al azar , al menos no tan a menudo como esta afirmación en negrita te haría pensar. No buenas pruebas, al menos, por lo que la calidad de las pruebas también es una cosa que tendrá que ser considerada seriamente. ¡Piense en marca CE , por ejemplo, que se trata de pruebas! ¿Los programadores tampoco están de acuerdo con que agregue valor real a los productos?

Sin embargo, el problema real con esta última declaración de OP citada es que parece sugerir que la administración realmente ha tomado el consejo de los programadores para externalizar las pruebas, o al menos se ha visto afectado por la aversión de los programadores a las pruebas, a diferencia de cómo otras respuestas pueden sugerir que la administración arruinó todo esto por sí mismo.

Los programadores son reacios a probar el código, porque (1) lo encuentran aburrido, y porque (2) si no prueban el código, parece que entregan la función más rápido.

Bueno, la administración se equivoca de vez en cuando, ¿verdad? Parece que se ha creado presión para ofrecer funciones rápidamente, y esto ha impregnado un poco la cultura. Desafortunadamente, las pruebas de reducción de esquinas y caída van de la mano cuando están bajo una presión excesiva para entregar.

Los programadores experimentados recorrerían un largo camino sobre cómo valen la pena las pruebas el tiempo , en lugar de quejarse de que se comen su tiempo y no pueden entregar valor, como dicen. Estoy en la posición de defensor del diablo de tener que dar una explicación simple de que los programadores son relativamente inexpertos, pero también, todo el sistema con el que están haciendo malabarismos no es tan complejo, por lo que todavía no han tenido demasiados problemas para sentir realmente valor de las pruebas automatizadas adecuadas.

Solo hay una sugerencia aquí que estaría en condiciones de dar y esta es esforzarse para que los desarrolladores sientan El valor real de las pruebas a toda costa. Además, mientras lo hace, mantenga los probadores externos y compongan las pruebas automatizadas adecuadas en la medida de lo posible. Si la salida no es demasiado complicada, crítica para la seguridad, etc., la compañía podría ¡probablemente prescindir del probadores externos, pero eso siempre depende de los detalles.

16
Vector Zita

No solo asuma que tiene razón acerca de depender demasiado de las pruebas de integración. Estás presionando por las cosas equivocadas. Tenga mucho cuidado al llevar a las personas a resultados medibles frente a resultados reales.

Medir, por persona, cuántos boletos vuelven a abrir los evaluadores (y compartir los resultados con todo el equipo).

Lo siento, pero esto es tonto. El trabajo de los programadores no se realiza cuando el código está en manos de un probador. Contar cuántas veces el código va y viene entre ellos contra el programador es contraproducente. Desea programadores comprometidos con probadores. No los castigue por hacerlo. Los buenos programadores animan a sus probadores. No se esconden de ellos.

Felicitar a las personas que obtuvieron los mejores resultados, es decir, aquellos que tienen la menor cantidad de entradas que se vuelven a abrir.

Esta no es una buena medida de lo mejor. Estás premiando a aquellos que pueden ocultar sus errores, no a aquellos que trabajan para verlos eliminados.

Dedique tiempo a programar con los que obtuvieron el peor rendimiento, tratando de entender por qué son tan reacios a probar su código y mostrándoles que no es tan difícil.

Todos los que ejecutan su código están probando su código. Cuando las personas no entienden cómo se les juzga, los inteligentes ni siquiera intentan adivinar. Simplemente se someten rápidamente al juicio y esperan aprender algo útil del resultado. Tenemos un término elegante para este comportamiento. Se llama ágil.

Ahora, por favor, no tome eso como que no me gusta la programación de pares. Me encanta. He aprendido más sentado con otros programadores que están trabajando en un problema que en cualquier libro o blog. No puedo esperar a que esta cosa codiciosa desaparezca para poder volver a hacerlo.

Pero no es programación en pareja si todo lo que haces es predicar. Si haces esto, cállate y escucha a tu pareja. Puede aprender algo y descubrir que su problema no es lo que cree que es.

Explicando que es mucho más rápido resolver un problema en este momento, que esperar varios días hasta que se pruebe la función.

Bueno, aquí está tu problema. No debería llevar varios días probar una función. Piensa en el código como el cemento. Cuanto más se sienta, más difícil es moverse. Obtenga comentarios de los probadores más rápido. Preferiblemente antes de comenzar a pensar en otras características.

Cuanto más tiempo se tarda en detectar un error, más costoso es repararlo.

Explicando que los probadores solo hacen pruebas del sistema, y ​​la falta de pruebas unitarias dificultan la localización exacta del problema.

Deja de explicar y haz prueba de unidad de pares. Les muestra lo que quieres. Los programadores se comunican mejor con el código. Esto les permite hacer eso.

Funciona así: escribo una prueba unitaria. Escribo el código de producción que pasa la prueba de mi unidad. Revisas el código por pares, notas algo hinky y escribes una prueba unitaria que prueba hinkyness. Me envías tu prueba de unidad, la reviso y la hago pasar o hablamos sobre cuál debería ser el requisito real. Realice pruebas de unidades pares y sus evaluadores de unidades débiles aprenderán de los más fuertes. Por extraño que parezca, los fuertes también aprenderán de los débiles.

Ah, y puedes hacer esto cuando emparejas el programa. Hace que todo vaya rápido.

Hablando de requisitos, si el probador de integración no es parte de la discusión sobre los requisitos, y cuáles son comprobables, antes de que comience esta codificación, está loco. Hacen la llamada sobre qué requisitos son comprobables de integración. Los codificadores deben saber cómo se desencadenó esto incluso antes de comenzar con un diseño.

Envía el código a los probadores de integración después de que haya pasado por una revisión y prueba por pares. Ahora, dos codificadores han elegido esto antes de tiempo y ambos deberían estar apoyando a los probadores para encontrar cualquier error restante. No deberían estar tratando de ocultarlos. Deben informar abiertamente cualquier cosa que pueda ayudar al probador de integración a encontrarlos.

No son programadores vs probadores. Todos somos contra los errores.

Así que deja de recompensar a las personas por crear código no comprobable.

6
candied_orange

Estoy firmemente en el campo de cobertura 100% automatizado. Creo que en realidad me ayuda a ir más rápido a largo plazo, y yo odio que un probador me devuelva las cosas.

Dicho esto, si la gente odia hacer pruebas automatizadas, debe proporcionar un incentivo para no tener que escribirlas. Si piensan que aún pueden mantener la calidad sin pruebas automatizadas, permítales demostrarlo. Requeriría pruebas automatizadas para cualquier error que los probadores les devuelvan, y de lo contrario las haré opcionales. En otras palabras, necesitan escribir una prueba que falle si el error reportado está presente, luego mostrar que pasa con su corrección, como requisito previo para que los probadores lo vuelvan a probar.

Lo que espero que suceda es que los programadores más descuidados terminarán teniendo que escribir la mayoría de las pruebas, lo que debería alentarlos a tener más cuidado. El código que es más fácil de romper terminará con la mejor cobertura. Es probable que las personas comiencen a escribir pruebas preventivas para cosas que son difíciles de probar manualmente, y que realicen pruebas manuales más exhaustivas para pruebas que son más difíciles de automatizar. Esperemos que también se invierta en hacer que las pruebas sean más fáciles de escribir y ejecutar. Muy poco cambiará para los programadores que ya tienen cuidado.

4
Karl Bielefeldt

Un par de puntos que realmente no veo en las otras respuestas.

Los conjuntos de habilidades para el desarrollo y las pruebas pueden superponerse pero algunas personas son excelentes evaluadores, y a veces no son las mismas personas que hacen grandes desarrolladores. Como desarrollador, un buen departamento de control de calidad vale su peso en oro; obligándome a hacer todas las pruebas por mí mismo, especialmente en un entorno donde el código de otra persona podría cambiar el comportamiento de una página web entre cuando lo pruebo y cuando se activa el conjunto combinado de cambios es ... lo contrario. Entonces, si tiene un flujo constante de cambios, probar el resultado final después de que se haya fusionado es bastante más importante.

Es probable que un desarrollador pueda decirle qué necesita pruebas, qué podría salir mal, etc. Escúchalos.

Otro punto que estoy viendo en el OP es que, en algún momento, después de que sus desarrolladores se acostumbraron a usar un marco de prueba, hubo una decisión de cambiar a otro, que se jacta en su sitio web de reducir el volumen de pruebas de integración, y pronto.

Usted no mencionó las razones por las que se tomó esta decisión, ni si se dedicó algún tiempo de capacitación o aprendizaje para este cambio. ¿Se esperaba que aprendieran este nuevo marco además de continuar trabajando al ritmo esperado en el desarrollo de características, corrección de errores, etc.

3
Will Crawford

Considere tomar esto en el hilo Gestión de proyectos.

Pero también, simplemente dígales que su trabajo no será aceptado a menos que vaya acompañado de pruebas automatizadas. "Sí, esto es parte de su trabajo". Los probadores externos están ahí solo para mantenerte honesto.

Como desarrollador de software de por vida yo mismo (así como también un gerente de proyectos de consultoría) Puedo hablar directamente con la cantidad de veces que siento que "mi a * s se salvó" por las pruebas que escribí , incluso de mi propio código en el que nadie más trabajaría, ya que lo estaba construyendo. I frecuentemente "no pude hacerlo bien". Y a veces me sorprendía cuando una prueba anterior de repente comenzó a fallar. Encontré y arreglé uno "¡te tengo!" después de otro ... antes de que tuviera una oportunidad. Y de esta manera construí capa sobre capa de código sabiendo que era correcto.

Obtenga soporte administrativo detrás de usted que "no se acepta hasta que se pruebe, y nos reservamos el derecho de rechazar sus pruebas".

3
Mike Robinson

Las revisiones pueden funcionar mejor en ese entorno.

Como desarrollador, siento lo mismo. Escribir pruebas es aburrido (particularmente pruebas unitarias). Y no siempre son efectivos (particularmente pruebas unitarias). Depende del tipo de lógica que escriba y del tipo de entrada que obtenga. Los requisitos 100% especificados no son tan comunes en mi experiencia, entonces, ¿qué probarían realmente sus pruebas? Requerir que las personas escriban pruebas unitarias solo porque puede ser desmotivador. También puede avergonzar a las personas que producen la mayoría de los "errores" (pueden ser los mismos que producen el mayor valor).

La presión de grupo es más efectiva. Tienes que acostumbrarte el uno al otro y esto puede doler un poco, pero al final tendrás un equipo. No obtendrá un equipo imponiendo reglas externas que no sean compatibles con las personas que tienen que seguirlas.

Incluso sugeriría abandonar por completo a los chicos de prueba en alta mar. Quiero decir, ¿por qué debería esforzarme por ofrecer un comportamiento perfecto cuando no se me confía para hacerlo de todos modos y de todos modos hay otra capa de verificación sobre mi trabajo? Aparentemente esta es la forma en que trabajamos, ¿verdad? Mientras estén allí, permítales hacerme la vida un poco más fácil y encontrar los cabos sueltos que pueda arreglar, para que no tenga que esforzarme demasiado.

Si esa red de seguridad no estuviera allí ... Sería más cuidadoso. Me sentiría respetado y responsable. Con una actitud como "vas a entregar basura para que tengamos todo lo que produzcas analizado", no me sentiría inclinado a esforzarme mucho.

2
Martin Maat

Nuestra organización resolvió el problema de que los desarrolladores nunca probaran sus cambios por sí mismos al hacer esa parte del proceso:

  1. Realizar un cambio en las pruebas requiere que proporcione documentación de sus cambios.
  2. La documentación debe hacerse utilizando la plantilla estandarizada.
  3. Esa plantilla incluye las siguientes secciones obligatorias:
    • ¿Cuál fue la razón del cambio?
    • ¿Qué fue cambiado?
    • Una "Prueba de funcionalidad" donde el desarrollador hace una prueba básica del cambio, documenta su ejecución y resultados con capturas de pantalla de una manera que muestra que se logró el objetivo del cambio. No se espera que esta prueba sea tan exhaustiva como una prueba realizada por el equipo de control de calidad real. Simplemente se supone que demuestra que ahora parece funcionar en lo que respecta al desarrollador.

De esa manera, cada desarrollador se ve obligado a ejecutar su código modificado al menos una vez.

2
Philipp

Necesita una "definición de hecho"

Las 'definiciones de hecho' generalmente aceptadas incluyen no solo el código de trabajo, sino también las pruebas de la unidad de trabajo y la documentación. Hasta que se completen esas cosas, la tarea no se realiza y el código no puede y no debe ser entregado al departamento de pruebas o Dios no lo quiera, en vivo.

Si bien a menudo encontrará el concepto bajo el paraguas Agile/Scrum, ese marco de trabajo no es necesario para implementar esta idea.

https://www.scruminc.com/definition-of-done/

https://www.agilealliance.org/glossary/definition-of-done/

Los evaluadores están ahí para detectar las cosas que no pensaste, casos de uso extraños o cosas que honestamente perdiste.

1
NKCampbell

Puede alentar a los desarrolladores a que no "confíen demasiado" en los probadores centrándose en los resultados que realmente están tratando de lograr (presumiblemente características que equilibran el costo de desarrollo con el valor que la empresa obtiene de su implementación a un cierto nivel de calidad) y permitiendo que los desarrolladores decidan cuánto confiar en los probadores para lograr este objetivo. En otras palabras, a menos que sea parte del equipo de desarrollo, está tratando de administrar algo que el equipo de desarrollo debería estar administrando.

Fijación "Hecho"

Lo primero que debe hacer es corregir su definición de "hecho". Usted dice que los desarrolladores

... a veces marcaría las características como hechas sin siquiera [comprobar] si funcionan en un navegador: dado que los evaluadores detectarán los errores, ¿por qué molestarse?

Primero, redefina "hecho" como "el cambio está listo para salir a producción, para que lo usen clientes reales". En segundo lugar, haga que cada desarrollador sea responsable de la gestión del proceso que obtiene un cambio particular en la etapa "hecho". Eso incluye garantizar que se completen las pruebas que el desarrollador considere necesarias, ya sea escribiendo y ejecutando pruebas automatizadas, enviando código e instrucciones de prueba a los evaluadores humanos y revisando los resultados, o cualquier otra cosa que se les ocurra.

Si se descubre que un cambio es defectuoso de alguna manera después de que el desarrollador lo haya declarado "hecho", ese es el momento de sentarse con el desarrollador y hacer una revisión. Esta revisión debe realizarse entre el desarrollador y uno o más miembros senior del equipo de desarrollo. (Puede o no incluir también a alguien del lado del propietario del producto; ver más abajo). Esta revisión no debe ser confrontativa y ciertamente no debe comenzar asumiendo que algo se hizo mal, sino examinar el impacto del lanzamiento (o que está por suceder) lanzado, si lo atrapó a tiempo) y considere qué medidas rentables podrían haberse tomado para evitar que eso suceda, es decir, lo que el desarrollador (y el equipo de desarrollo) deberían cambiar para mejorar las cosas. (La respuesta bien podría ser: "Nada. El costo de prevenir todas o la mayoría de estas cosas es más que el costo de vivir con ellos").

El propietario del producto en tales reuniones, si está presente, no está allí para presionar al equipo para que realice cambios técnicos o de procedimiento, sino por otras dos cosas: 1. para proporcionar información sobre el costo del impacto comercial negativo de la publicación (o costo estimado, si el defecto quedó atrapado a tiempo) y 2. para evaluar si el propietario del producto desea pagar costos adicionales para evitar este tipo de problema. (Por ejemplo, los desarrolladores dicen, "podemos reducir la incidencia de este tipo de cosas en un 50%, pero retrasará el desarrollo en un 5%"; el propietario del producto puede decidir si la mayor calidad en el lanzamiento vale la tasa más lenta de obtener características implementadas.)

Los desarrolladores gestionan las pruebas

Enviar cambios a probadores humanos no es, en un alto nivel, muy diferente de escribir pruebas automatizadas. Hay algún tipo de secuencia de comandos para que los probadores o el sistema de prueba sigan (incluso si es un simple como, "ve a esta URL y dime lo que piensas") y el desarrollador evalúa los resultados para decidir si ha terminado o si necesita hacerlo. más trabajo (ya sea cambiando el código o ejecutando más pruebas).

Este script debe guardarse en algún lugar donde pueda ser revisado por otros desarrolladores en (o en preparación para) las reuniones que describí anteriormente. Y el historial de cambios también debe mantenerse, de modo que, p. Si un desarrollador eliminó algo de él (tal vez porque agregó pruebas automatizadas para cubrir algo que era problemático o que los evaluadores humanos demoraron demasiado), la revisión puede examinar esa decisión. (Personalmente, generalmente guardaría esta información en el repositorio de código fuente, en archivos de texto o de descuento, pero los desarrolladores deberían hacer lo que sea mejor para ellos y el equipo de prueba).

El guión inicial probablemente incluiría la historia del propietario del producto, instrucciones sobre cómo configurar todo lo necesario para probar ese bit de código y cualquier otra nota que el desarrollador considere útil.

Como con cualquier cosa, los desarrolladores que no tienen experiencia con esto probablemente necesitarán algún apoyo de otros en el equipo de desarrollo. No esperaría que un desarrollador con poca experiencia en pruebas unitarias pueda escribir buenas pruebas unitarias desde el principio, o incluso descubrir qué necesita ser probado; Lo mismo ocurre con la gestión de las pruebas manuales.

Pero los desarrolladores deben estar atentos al objetivo aquí: poder declarar algo como "hecho" con el significado de que creen que pasará todas las pruebas de aceptación realizadas por el propietario del producto, o que lo haría el propietario del producto si no confiaba tanto en los desarrolladores, e incluso en cualquier prueba en la que el propietario del producto pudiera pensar después de que el desarrollador tuvo la historia y comenzó a codificarla.

Aceptación

Hay algo que eludí un poco más arriba, que es que realmente hay dos etapas "terminadas", bajo el control de equipos separados. La primera es la etapa "terminada" del equipo de desarrollo, lo que significa "Espero que esto pase todas las pruebas de aceptación", como se mencionó anteriormente. El segundo es el propietario del producto "Acepto este cambio; publíquelo". La cantidad de trabajo que realiza el propietario del producto en este lado depende de qué tan bien esté haciendo el equipo de desarrollo. Cuando un equipo de desarrollo ha demostrado ser muy confiable para interpretar los requisitos y escribir el código que los cumple, el propietario del producto puede realizar pruebas mínimas. Cuando el equipo de desarrollo no está haciendo un trabajo tan bueno en esto, el propietario del producto tendrá que realizar más verificaciones.

El lugar en el que se encuentra actualmente en este espectro no es demasiado importante: lo importante es que, cuando falla la prueba de aceptación, el equipo de desarrollo revisa cómo falló (es decir, por qué consideraron incorrectamente que se había "hecho" cuando no lo estaba) y se desarrolla sistemas para prevenir futuras fallas similares en las pruebas de aceptación. Mejorar esto en cualquier caso particular puede ser un asunto técnico puramente interno para el equipo de desarrollo, o algunas fallas pueden deberse a problemas de comunicación entre el propietario del producto y el equipo de desarrollo, en cuyo caso deben trabajar juntos para resolver Cómo arreglar eso.

Resumen

Escribir pruebas automatizadas y enviar código a un equipo de prueba son simplemente dos métodos diferentes para lograr el objetivo de garantizar que un cambio sea de calidad suficiente para su lanzamiento. Casi siempre se usan juntos, y la decisión sobre cuánto de cada uno de ellos debe recaer en el desarrollador que realiza el cambio, porque está íntimamente afectada por la forma en que elige escribir su código. Entonces ella debería estar manejando eso, y necesita todo el apoyo necesario para ser bueno en la gestión de eso.

1
cjs

Parece que la política fue de un extremo al otro. Nunca he visto trabajar en la práctica una cobertura de prueba del 100%. La compensación entre la cantidad de tiempo y los detalles necesarios para escribir una prueba para una función y el beneficio de la prueba en sí misma suele ser muy variable. Obligar de manera contundente una cobertura de prueba del 100% sin considerar la compensación, eventualmente obligará a los desarrolladores a tomar más tiempo del necesario para escribir algunas pruebas.

Un enfoque flexible sería mejor. Exija un mínimo de cobertura de prueba y dígales a los desarrolladores que intenten juzgar cuán difícil sería escribir la prueba para una función. Sin embargo, otra persona que no sea el desarrollador mismo debe hacer una revisión, verificar qué funciones están sujetas a cambios frecuentes o tienen requisitos tan complejos que podrían romperse fácilmente y marcar esas funciones como las que necesitan una prueba sin importar qué.

Otra cosa que ayudaría es encontrar al desarrollador más hábil con las herramientas de prueba y pedirle que desarrolle algunas plantillas para la parte más difícil. A menudo, encontrar cómo construir los simulacros en torno a una función particular realmente lleva mucho tiempo. Un conjunto de patrones/solución al alcance de la mano ahorraría mucho tiempo.

0
FluidCode

Hay una solución muy simple.

Usted convoca una reunión con sus desarrolladores. En esa reunión, usted les dice: "Tenemos un problema con nuestro proceso en este momento. Parece que, por el momento, el código que se envía muy a menudo no funciona correctamente. Eso hace que el control de calidad pase demasiado tiempo escribiendo informes de errores, y luego cuesta tiempo de desarrollo arreglando esos errores. Anteriormente teníamos el problema de que el desarrollo era de una calidad extremadamente alta, pero a un costo enorme. Necesitamos llegar a un punto en el medio, donde los desarrolladores pasan un poco más de tiempo para asegurarse de que haya no pasaron demasiados problemas al control de calidad, por lo que podemos trabajar de manera más eficiente en general ".

Algunas respuestas están demasiado centradas en la dificultad para encontrar el mejor punto. Eso no es obligatorio. Tenías un punto en un extremo que era ineficiente, ahora tienes un punto en el otro extremo que es ineficiente, ir más al medio será una mejora. No ignore una mejora solo porque no puede encontrar el punto óptimo.

0
gnasher729

Acaba de responder sus preguntas, cuando se publicaron los dos temas: "Los programadores son reacios a probar el código, porque (1) lo encuentran aburrido, y porque (2) si no prueban el código, parece que entregar la función más rápido ". Qué significa eso? Cómo se realiza la entrega, si no hay pruebas, que están planificadas. Cualquier proyecto/módulo se puede entregar (incluso poner en un repositorio GIT) solo después de maven o gradle o qué más ha ejecutado todas las pruebas a lo largo de la compilación. ¿Qué es una entrada de desarrollo de una unidad? Los analistas o arquitectos deben proporcionar una lista de casos, que deben estar sujetos a pruebas para un componente, o en el peor de los casos, los ingenieros de prueba (son responsables de las pruebas) primero colocan las pruebas en el repositorio y los desarrolladores las obtienen a pedido. Maven/gradle hará el trabajo. Además de una entrega debe pasar una revisión de código con la primera atención a la prueba. Y solo entonces, los cambios pueden fusionarse con la rama que usamos para la construcción industrial. Sin pruebas, sin entrega, ¡el trabajo no está hecho! Eso es todo.

"Pase tiempo programando pares con aquellos que obtuvieron el peor rendimiento, tratando de entender por qué son tan reacios a probar su código y mostrándoles que no es tan difícil". Realmente, el elemento de XP como Programación por pares no está dedicado a mostrar ABC a los desarrolladores, que son reacios a hacer una parte del trabajo. Pruebas: no solo son pruebas, es una parte (importante) de su trabajo, que debe estar en la definición de posición. El enfoque que ha mencionado es pasar tiempo no solo con los probadores, sino también con otros desarrolladores, a menos que esté en la primera etapa de una adsorción recién llegada (¡principiante!). Su entorno, incluido DevOps, debe construirse de acuerdo con el principio: solo debe ir un componente que pase todas las pruebas PREDEFINED. De lo contrario, no se entrega.

0
Simon