Por qué dejar / no dejar que los desarrolladores prueben su propio trabajo

Quiero reunir algunos argumentos sobre por qué dejar que un desarrollador pruebe su propio trabajo como último paso antes de que el producto entre en producción es una mala idea, porque desafortunadamente, mi lugar de trabajo a veces hace esto (la última vez que esto surgió , el argumento se redujo a que la mayoría de las personas están demasiado ocupadas con otras cosas y no tienen tiempo para familiarizar a otra persona con esa parte del programa: es un software muy especializado).

Hay planes de prueba en este caso (aunque no siempre), pero estoy muy a favor de hacer que una persona que no realizó los cambios que se prueban realmente realice la prueba final. Así que le pregunto si podría proporcionarme una buena y sólida lista de argumentos que pueda presentar la próxima vez que se discuta esto. O para proporcionar contraargumentos, en caso de que piense que esto está perfectamente bien, especialmente cuando hay casos de prueba formales para probar.

Como otros (y usted) han notado, los desarrolladores deberían probar su propio código. Sin embargo, después de eso, cualquier producto no trivial también debe ser probado por personas independientes (departamento de control de calidad y / o el propio cliente).

Los desarrolladores normalmente trabajan con la mentalidad de desarrollador de "¿cómo hacer que esto funcione?" . Un buen probador está pensando en "¿cómo romper esto?" - Una mentalidad muy diferente. Las pruebas unitarias y TDD enseñan a los desarrolladores a cambiar los sombreros hasta cierto punto, pero no debe confiar en ello. Además, como otros han señalado, siempre existe la posibilidad de malentendidos en los requisitos. Por lo tanto, las pruebas de aceptación final deben ser realizadas por alguien tan cercano al cliente como sea posible .

El desarrollador sabe cómo funciona su código y tendrá la costumbre de probar su código de acuerdo con este conocimiento.

El desarrollador tendrá dificultades para eliminarse de la mentalidad de "cómo funciona" en lugar de "cómo debería funcionar".

Debido a esto, es mejor hacer que alguien con un alto grado de objetividad pruebe el programa, es decir, QA o ingenieros de prueba.

Probadores Prueba para romper, simple. Este tipo de sesgo es necesario para descubrir realmente los topes del espectáculo.

Los desarrolladores DEBEN probar su trabajo. Es una responsabilidad implícita.

Supongo que no tiene un equipo dedicado para hacer las pruebas basadas en su declaración. Sin embargo, tener un equipo dedicado a las pruebas realmente ayudará, ya que los desarrolladores tienden a probar su código de la forma en que lo codificaron. No significa que una vez que tenga un equipo de garantía de calidad de algún tipo, ya pueda realizar las pruebas como responsabilidad de los desarrolladores.

Los desarrolladores suelen utilizar redes con grandes agujeros para atrapar errores. Como resultado, escapan los errores más pequeños.

Porque los desarrolladores no son buenos para tratar de romper su propio código. Su mente simplemente sigue la ruta correcta de entrada de datos e interacción con la aplicación. Muchos errores son el resultado de interactuar con el sistema como un chico normal . Los desarrolladores no son usuarios normales. Son usuarios profesionales.

Hay algunas buenas razones para tener un equipo de pruebas dedicado. Primero, como se mencionó anteriormente, los desarrolladores son muy buenos para probar que su código funciona, pero no lo rompen.

Además, como usted dice, un desarrollador sabe lo que escribió, pero un equipo de prueba sabe lo que debería haber escrito. A veces, estos dos conceptos no coinciden. Uno de los trabajos del equipo de prueba es asegurarse de que el software cumpla con los requisitos. En muchos casos, un desarrollador solo conoce algunas partes del sistema muy bien, pero el equipo de control de calidad lo sabe todo.

Lo que lleva a la siguiente razón, los equipos de prueba realizan pruebas de integración completa. El código que acaba de escribir podría funcionar bien por sí mismo, pero podría romper otras funciones que no conocía.

Después de haber trabajado con un equipo de control de calidad y sin él, puedo decirle que aprecio al 100% el trabajo que realizan y diré que son una parte valiosa del equipo de software. Cuando tienes un equipo de control de calidad, hace que la liberación de tu código sea mucho más fácil, porque sabes que se ha probado exhaustivamente y eso significa que recibirás menos llamadas a las 3 a.m.

Los desarrolladores deberían probar su propio código.

Los probadores independientes no solo prueban para romper, sino que prueban las suposiciones no definidas e indefinidas que los desarrolladores hicieron durante la codificación.

Esperaría que el desarrollador haga algunas pruebas iniciales antes de confirmar cualquier cambio y que se haya convencido de que el código funciona. Entonces esperaría que el desarrollador alimente en los casos de prueba cualquier conocimiento específico de 'caja blanca' que tengan. Por ejemplo, detalla cualquier otra área del código que pueda haber sido afectada.

La principal objeción para que los desarrolladores prueben su propio código es que solo está probando un punto de vista. El desarrollador ha leído la especificación y la ha interpretado. Esperemos que la especificación sea clara, completa y sin ambigüedades, pero este no es siempre el caso. El desarrollador puede haber entendido mal parte de la especificación. Si prueban su propio código, esto no se detectará, ya que encontrarán que la función funciona como esperan.

Diferentes personas también tenderán a usar un producto de manera diferente y, como resultado, tomarán diferentes rutas a través del código. Un desarrollador se habrá asegurado de que el código funcione para ellos, pero puede que no haya considerado un caso límite que otro probador puede encontrar.

Los desarrolladores deben probar su propio trabajo. Permitir que los desarrolladores envíen trabajo no probado a un equipo de control de calidad, o sus colegas desarrolladores es una muy mala idea. Pierde el tiempo de desarrolladores y probadores por igual, y arruina las relaciones.

Sin embargo, eso no siempre es suficiente. Es probable que los desarrolladores sigan un camino feliz a través del sistema, o sean ciegos a algunas idiosincrasias a las que han estado expuestos una y otra vez durante el desarrollo.

Otro punto es que puede haber una serie de capas de comunicación entre la especificación y la implementación. Esto puede conducir a un efecto de susurros chinos en el despliegue final. Es mejor si quien definió el requisito o el informe de error prueba que funciona de la manera que quería.

Como desarrollador, usted es responsable de su propio código, debe probarlo. Does the feature work as expected?Si la respuesta es sí, ya está.

¿Por qué no deberías hacer casos de prueba?

1. Eres subjetivo , ya que los errores encontrados los escribes tú (o tus colegas).
2. Usted es demasiado caro para que la empresa realice pruebas de casos. (Espero).

Por lo general, los desarrolladores no serán, en la mayoría de los casos, los que usarán el código, excepto en ciertos casos especializados. Entonces, el último paso de prueba antes de la promoción a un sistema de producción debe ser la prueba de aceptación del usuario, UAT. Generalmente [se supone que están] más familiarizados con lo que esperan que haga el paquete. Y generalmente son más capaces de romper cosas con flujos de entrada desconocidos para alguien que no lo usa a diario.

¿Sus planes de proyecto no satisfacen las pruebas de los usuarios? Si logra que los usuarios lo prueben, puede detectar errores antes de la implementación posterior, lo que en mi mundo no es malo.

Los desarrolladores no deberían probar su propio código porque eso es similar a juzgar el arte de su propio hijo. Te parecerá hermoso de cualquier manera, y realmente necesitas un profesional para señalar los defectos. Por otro lado, las pruebas unitarias son similares a garantizar que su hijo no intente pintar con plomo.

En caso de que ustedes REALMENTE no quieran contratar QA, hagan que los desarrolladores escriban código de prueba para otros desarrolladores. Ese es un buen primer paso: pronto verá que los desarrolladores solicitan recursos de control de calidad porque la mayor parte de su tiempo se dedica a probar el código de otros problemas, además de CR.

No solo los desarrolladores protegen su código, si no se dan cuenta de un caso en particular o si interpretan erróneamente una especificación en la forma en que desarrollan algo, se perderán esos casos al probar su código.

Las técnicas y habilidades para las pruebas también son muy diferentes.

La mayoría de las pruebas realizadas por un equipo de prueba es funcional (que un producto funciona según una especificación) y caja negra (el equipo de prueba no verá el funcionamiento interno de una aplicación). Los probadores funcionales no necesitan preocuparse por cómo funcionan las cosas, solo necesitan enfocarse en si lo hacen.

En mi experiencia, al menos en mi pequeña organización, el usuario final necesita realizar una prueba. Casi todos los proyectos que obtenemos, no proporcionan toda la información necesaria y siempre omiten ciertos detalles. El desarrollador siempre está en desventaja de prueba porque no sabe cómo hacer el trabajo del usuario, por lo que si bien sabe que el software funciona de acuerdo con la información que se le proporcionó, no sabe si ayudará al usuario final hacer su trabajo

Los desarrolladores malinterpretan y malinterpretan los requisitos y los responsables de los requisitos a menudo no pueden especificar las cosas clave. Si nadie, excepto las pruebas del desarrollador, nadie encontrará estas desconexiones antes de comenzar a funcionar. Cuando los desarrolladores prueban, saben demasiado sobre cómo se supone que funciona y no prueban las cosas estúpidas que los usuarios podrían intentar. Los desarrolladores también escriben sus pruebas en función de su propia interpretación del requisito, que con demasiada frecuencia no es lo que realmente se quiso decir. Entonces las pruebas pasan pero el requisito no se cumplió. Cuando se realiza una prueba con una persona diferente, esa persona puede tener una idea diferente de los requisitos y, a menudo, se encuentran los lugares donde el requisito se expresó mal por la forma diferente en que dos personas diferentes lo interpretan. Mucho mejor descubrir esto en las pruebas que después de que salgas al mercado.

El Desarrollador debe hacer la prueba inicial para que sepamos que la pieza que hemos codificado funcionaría de la forma en que se espera que funcione, según los requisitos que tenemos. Así que tenemos que hacer las pruebas normales, así como escribir pruebas unitarias para el código que hemos escrito.

El siguiente paso es el trabajo de QA para descubrir lo que los desarrolladores no ven cuando escribimos el código. Un desarrollador piensa en un nivel superior pero el usuario puede no pensar en el mismo nivel. Cuando el desarrollador está probando su pieza y tiene que ingresar algo de texto en un cuadro de texto, siempre puede ingresar una cadena completa pensando que el usuario también lo haría. Puede ser que el usuario también lo haga, pero al azar cuando ingresa un carácter especial como% & $ ^ en el texto y eso rompe la aplicación, no se ve bien para el usuario final. Un desarrollador no puede y no pensará en todas las posibilidades que podrían suceder porque no está capacitado para pensar de esa manera. Cuando se trata de un QA (probador), siempre piensan en lo que el usuario podría hacer para romper esta aplicación e intentan cada cosa estúpida del libro, no los usuarios son estúpidos, pero no debemos dejar nada al azar.

Ahora también tenemos que entender que generalmente se hace más de una pieza al mismo tiempo y ambas irán a producción. El desarrollador podría probar solo su pieza y pensar que está funcionando bien, pero la prueba de regresión general debe hacerse para todas las piezas que se están presionando, así como para descubrir que la combinación de dos piezas diferentes podría romper la aplicación y lo hace. No se ve bien tampoco. También tenemos que considerar los escenarios de prueba de carga y otras cosas que los evaluadores conocen más.

Finalmente, tenemos que pasar por UAT (Prueba de aceptación del usuario) para ver si lo que hicimos es lo que se esperaba. En general, aunque los requisitos superan los BA, la persona final podría no saber exactamente cómo se ve y él / ella podría pensar que no es lo que esperaban o tal vez quieran agregar algo más para que se vea mejor o por alguna razón podrían descartar el pieza completa ya que piensan que la pieza no iría con la funcionalidad ya disponible.

Como se explicó anteriormente, estos son muy importantes y no pueden ser realizados solo por el desarrollador y son absolutamente necesarios para que la aplicación funcione bien. La gerencia puede decir que este es un enfoque conservador, pero es el mejor enfoque. Podemos hacer algunos ajustes a lo dicho anteriormente, pero no podemos evitarlo en su conjunto.

Los comentarios anteriores plantean grandes puntos.

Otro adicional no mencionado anteriormente es que tener un código de prueba individual separado actúa como una verificación adicional de los requisitos y si el sistema los implementa correctamente.

Los requisitos y la documentación no son perfectos y, a menudo, la implementación es el resultado de la interpretación de los requisitos por parte de un desarrollador.

Cuando la prueba es realizada por un individuo separado, también proporcionan su propia interpretación de los requisitos al crear el plan de prueba y ejecutar las pruebas.

Cuando las actividades de prueba se realizan independientemente de las actividades de desarrollo, y los resultados de ambos "acuerdan", proporciona una confirmación adicional de que el sistema es correcto y realmente coincide con la intención original de los requisitos.

Un programador, cuando realice la prueba, verá un cuadro de texto con la etiqueta "Cantidad" e ingresará "1". Un programador altamente experimentado realizará una prueba de seguimiento con el valor "2".

Un usuario verá un cuadro de texto con la etiqueta "Cantidad" e ingresará "~~ unicornios ROX !!! ~~". Un usuario experimentado también intentará "-12 1/2".

Con suerte, un probador estará allí en algún lugar para alertar al programador sobre lo que el usuario experimentará cuando haga estas cosas.

Una razón es porque los desarrolladores están demasiado cerca de su propio código. Saben que son caprichos, son pequeños comportamientos extraños. Tienden a probar alrededor de las pequeñas idiosincrasias que conocen tan bien. No son lo suficientemente objetivos al respecto. Los equipos de prueba lo tratan como una caja negra. Escriben matrices de docenas o cientos de casos de prueba y los analizan metódicamente para ver qué hará el código. A menudo se les ocurren escenarios con los que el equipo de desarrollo nunca soñaría.

Otra razón es el tiempo. Para proyectos grandes que se construyen en etapas, el equipo de desarrollo construirá la Etapa 1. Luego, los evaluadores la probarán mientras se construye la Etapa 2 y se reparan los defectos de la Etapa 1. Esto continúa para todas las etapas, por lo que la etapa que se está probando es la anterior que se creó.

Quiero reunir algunos argumentos sobre por qué dejar que un desarrollador pruebe su propio trabajo como último paso antes de que la prueba entre en producción es una mala idea, porque desafortunadamente, mi lugar de trabajo a veces hace esto (la última vez que esto surgió , el argumento se redujo a que la mayoría de las personas están demasiado ocupadas con otras cosas y no tienen tiempo para familiarizar a otra persona con esa parte del programa: es un software muy especializado).

Las pruebas no son opcionales para un desarrollador. Un desarrollador tiene que probar el código que escribió. ¿De qué otra manera puede estar seguro de que la tarea se ha realizado con éxito? Usted tiene que escribir algún tipo de pruebas automatizadas (pruebas unitarias) o realizar el trabajo de verificar "si la máquina está haciendo lo que quiero que haga" manuall (utilizando la GUI, llamando al comando en la línea de comando o lo que sea).

Todo lo que se está probando después de eso es "solo" pruebas adicionales realizadas por otras personas (compañeros de trabajo, control de calidad, ...). No hay alternativa a las pruebas directas realizadas por un desarrollador. Todos los que me dicen que un desarrollador no tiene que probar (o incluso no se le permite) el código / característica que escribió simplemente no comprenden cómo se está desarrollando el software.

Lo prueba alguien que no está familiarizado con el código, le guste o no. La pregunta es si quieres que alguien sea tu cliente.

Gran pregunta En su situación, existen casos de prueba, a veces, y el software parece ser lo suficientemente complejo como para que no sea práctico poner al día a un novato en el producto. También dice que la prueba realizada es la prueba final antes de la producción.

Motivos por los que podría estar bien que el desarrollador haga la prueba final

• Hay suficiente otra cobertura de prueba ... Existen pruebas unitarias, existe un entorno de prueba de integración y se utiliza, se han realizado pruebas de IU, pruebas exploratorias, etc., etc. Luego, una prueba final es un criterio de aceptación menos riguroso que una prueba final " ejecutar a través de"
• Existe un conjunto de casos de prueba escritos por un profesional SQA / Tester que alguien (un desarrollador) puede / necesita seguir explícitamente
• El riesgo de falla de la función / producto / módulo se ha mitigado a niveles bajos (deje que el profesional pruebe las áreas de alto riesgo y un "novato" pruebe el riesgo más bajo)
• La realidad de la situación empresarial es que lanzar un producto con defectos potenciales es mejor que retrasar el lanzamiento.
• El desarrollador en cuestión es en realidad un probador muy calificado también y es capaz de hacer un cambio mental en los roles.
• El cambio es una corrección de errores realizada en el campo por el desarrollador cuando el sitio del cliente se cierra o pierde ingresos debido a que el sistema está fuera de línea (un parche que será devuelto a la oficina y probado / lanzado en una versión controlada lo antes posible) )

Razones por las que un desarrollador no debe hacer la prueba

• Algo más

En general, parece que está en el camino correcto para atacar la solución real: haga que el experto SQA genere los casos de prueba ...

Nota: Por lo general, estoy a favor de dejar que los desarrolladores realicen las pruebas, pero me aseguro de que exista el primer punto ...

Los seres humanos, siendo humanos, tienden a sufrir sesgos cognitivos, donde su juicio en dos escenarios casi idénticos diferirá, simplemente debido a algunas cosas que han cambiado, una cosa que he notado en 8 años de desarrollo, es que cuando un desarrollador se enfrenta a probar su propio código, a diferencia del código que ha escrito un colega, las pruebas realizadas en su propio código son de peor calidad.

Esto no quiere decir que el desarrollador tenga la culpa directamente: su cerebro utilizará el sesgo que lo escribió para reforzar el hecho de que cree que es correcto y solo realizará comprobaciones básicas, en lugar de un desarrollador que está mirando el código de otra persona, hará muchas verificaciones más exhaustivas.

Existen miles de ejemplos en los que se ha implementado un procedimiento para prevenir el sesgo cognitivo, o comúnmente conocido como "El factor humano", como los sistemas computarizados en el control del tráfico aéreo, para evitar que dos aviones diferentes ocupen el mismo espacio aéreo al mismo tiempo. tiempo, a los procedimientos médicos establecidos para que más de un médico tenga que dar un diagnóstico.

Ya es hora de que la industria de TI avance hacia una actitud más profesional y establezca procedimientos para evitar la prueba de su propio código.

• Todos deberían probar: código de prueba de Develpers, funcionalidad de prueba de QA'ers, mensajes de prueba de marketing. De esa manera, todos comparten las mismas filosofías y lenguaje en torno a las pruebas, que es la mitad de la batalla.

• Las pruebas son tareas de mantenimiento de rutina y generalmente uso analogías para comparar . Por ejemplo, la analogía del cambio de aceite del automóvil. Nunca 'tienes que' cambiar tu aceite. Pero lo haces regularmente de todos modos. Lo mismo para cepillarse los dientes. Hay una razón por la que los mantiene a diario: no se romperán 'hoy', se trata de mañana y días futuros y de hacer una inversión.

• Todos deberían compartir la responsabilidad de la prueba. Un equipo de control de calidad es importante, sin embargo, hacer "pruebas" como algo que solo el equipo de control de calidad hace que sea una actividad "separada" que no se integra al desarrollo de productos y al flujo de trabajo, lo que no es bueno.

• Cuando algo se rompe en la producción, haz dos cosas:

  1. Di "hmm, tenemos una prueba para eso " como primer comentario.
  2. Haga que cualquier corrección incluya pruebas para el problema , primero para reproducir, que corregir.

En mi empresa, creamos algunas aplicaciones financieras bastante complejas. Nuestra política general es que el desarrollador debe asegurarse de que no surjan errores técnicos. Básicamente, intente todo lo posible para romperlo, dados los recursos del usuario. Cuando no pueda encontrar un error de tiempo de ejecución, envíelo a los BA para que lo prueben. Hemos tenido algunos desarrolladores que se perdieron al probar los requisitos comerciales hasta el punto de agotarse, pero solo porque todas esas pruebas no eran su responsabilidad. A menos que haya un error evidente que sea claramente visible, lo enviamos a las personas a las que se les paga para que comprendan el resultado. Además, los usuarios deben tener un papel real en la verificación de los resultados. El empleado de ventas en una tienda minorista no se prueba la ropa por usted, solo le ayuda con los "detalles técnicos" como encontrar ropa del tamaño correcto.

Un problema es que los desarrolladores tienen pocos incentivos para descifrar su propio código: pocas personas están dispuestas a buscar defectos en sus propios trabajos o están dispuestos a cometer errores. Tener un equipo separado ayuda a garantizar que las cosas se rompan.

Un rol de Garantía de calidad es esencial, entre otras razones, para que alguien pueda verificar que el desarrollador haya entendido los requisitos. El desarrollador no puede hacer esta verificación por sí mismo porque si pensaran que han entendido mal, pedirían una aclaración.