Por qué no permitir que los desarrolladores prueben su propio trabajo

Como otros (y usted mismo) han señalado, los desarrolladores deben probar su propio código. Sin embargo, después de eso, cualquier producto no trivial también debe ser probado por persona (s) independiente (departamento de control de calidad y / o el cliente).

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

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

Al desarrollador le resultará difícil eliminarse de la mentalidad de "cómo funciona" en lugar de "cómo debería funcionar".

Debido a esto, es mejor conseguir que alguien con un alto grado de objetividad pruebe el programa, es decir, el control de calidad o los ingenieros de prueba

Testers Test to break, Simple. Este tipo de sesgo es necesario para descubrir realmente los tapones del show.

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

Supongo que no tiene un equipo dedicado a realizar las pruebas según 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 control de calidad de algún tipo, ya pueda realizar las pruebas como responsabilidad de los desarrolladores.

  

Los desarrolladores usualmente usan redes con enormes agujeros para atrapar errores. Como resultado, los errores más pequeños se escapan.

Porque los desarrolladores no son buenos para intentar romper su propio código. Su mente simplemente sigue el camino correcto de la entrada de datos y la 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.

También, como usted dice, un desarrollador sabe lo que escribieron, pero un equipo de pruebas sabe lo que debería haberse escrito. A veces, estos dos conceptos no coinciden. Uno de los trabajos del equipo de pruebas es asegurarse de que el software cumpla con los requisitos. En muchos casos, un desarrollador solo conoce muy bien algunas partes del sistema, pero el equipo de control de calidad lo sabe todo.

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

Habiendo trabajado con un equipo de control de calidad y sin él, puedo decir que aprecio al 100% el trabajo que realizan y diré que son una parte valiosa del equipo de software. Cuando tiene un equipo de control de calidad, hace que la liberación de su código sea mucho más fácil, porque usted sabe que ha sido probado exhaustivamente y eso significa que recibirá menos llamadas a las 3am.

Los desarrolladores deben probar su propio código por unidad.

Los evaluadores independientes no solo hacen pruebas para romper, sino que también prueban las suposiciones no declaradas y no definidas que los desarrolladores hicieron durante la codificación.

Espero que el desarrollador realice algunas pruebas iniciales antes de confirmar los cambios y se haya convencido de que el código funciona. Entonces esperaría que el desarrollador incorporara en los casos de prueba cualquier conocimiento específico de "caja blanca" que tenga. Por ejemplo, detalla cualquier otra área del código que pueda haber sido afectada.

La principal objeción a 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. Es de esperar que la especificación sea clara, completa e inequívoca, pero no siempre es así. 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 es posible que no haya considerado un caso límite que otro probador pueda encontrar.

Los desarrolladores deben probar su propio trabajo. Permitir que los desarrolladores envíen trabajos no probados a un equipo de control de calidad, o sus colegas desarrolladores, es una idea realmente mala. Se desperdicia el tiempo de desarrolladores y evaluadores, 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 a lo largo del desarrollo.

Otro punto es que puede haber una cantidad de capas de comunicación entre la especificación y la implementación. Esto puede llevar a un efecto de susurros chinos en el despliegue final. Es mejor que quienquiera que haya definido el requisito o el informe de errores pruebe que funciona de la manera deseada.

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

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

1. Eres subjetivo , ya que los errores encontrados están escritos por ti (o tus colegas).
2. Es demasiado costoso para que la empresa realice pruebas de casos. (Espero).

Normalmente, los desarrolladores no serán, en la mayoría de los casos, los que usan el código, excepto en ciertos casos especializados. Por lo tanto, 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. En general, [se supone que] están más familiarizados con lo que esperan que haga el paquete. Y, en general, son más capaces de romper cosas con flujos de entrada desconocidos para alguien que no los usa a diario.

¿Sus planes de proyecto no se adaptan a 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 deben probar su propio código porque es similar a juzgar el arte de su propio hijo. Se verá hermoso para usted de cualquier manera, y realmente necesita un profesional para señalar las fallas. Por otro lado, las pruebas unitarias son similares a asegurarse de que su hijo no intente pintar con plomo.

En caso de que ustedes REALMENTE no quieran contratar el control de calidad, haga que los desarrolladores escriban códigos de prueba para otros desarrolladores. Ese es un buen primer paso: pronto verás a los desarrolladores pidiendo recursos de control de calidad porque la mayoría de su tiempo se invierte en probar el código de otros en busca de problemas, además de CR.

No es solo que los desarrolladores protejan su código, si no se dan cuenta de un caso en particular, o malinterpretan 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 la prueba también son muy diferentes.

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

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

Los desarrolladores interpretan mal y malinterpretan los requisitos y los responsables de los requisitos a menudo no especifican cosas clave. Si nadie, excepto el desarrollador, prueba, nadie encontrará estas desconexiones antes de su puesta en marcha. Cuando los desarrolladores hacen pruebas, saben mucho sobre cómo se supone que funciona y no intentan las estupideces que los usuarios pueden probar. Los desarrolladores también escriben sus pruebas basándose en su propia interpretación del requisito, que con demasiada frecuencia no es lo que realmente significaba. Así que las pruebas pasan pero el requisito no se cumplió. Cuando tiene una prueba de persona diferente, esa persona puede tener una idea diferente de los requisitos y, a menudo, encuentra los lugares en los que el requisito se expresó pobremente por la manera en que dos personas diferentes lo interpretan. Mucho mejor descubrir esto en las pruebas que después de que salgas en vivo.

El desarrollador debe realizar las pruebas iniciales para que sepamos que la pieza que hemos codificado funcionará de la manera que se espera que funcione, según los requisitos que tenemos. Así que hemos realizado las pruebas normales y las Pruebas unitarias para el código que escribimos.

El siguiente paso es el trabajo de control de calidad para averiguar qué es lo que los desarrolladores no ven cuando escribimos el código. Un desarrollador piensa en un nivel superior, pero el usuario podría no pensar en el mismo nivel. Cuando el desarrollador está probando su pieza y tiene que ingresar un texto en un cuadro de texto, siempre podría ingresar una cadena completa, ya que el usuario también lo haría. El usuario también puede hacerlo, pero al azar, cuando ingresa un carácter especial como% & $ ^ en el texto y eso rompe la aplicación, no se ve bien en el usuario final. Un desarrollador no puede y no pensará en todas las posibilidades que podrían ocurrir porque no está entrenado 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 y probar todas las estupideces del libro, no los usuarios son estúpidos, pero no debemos dejar nada al azar.

Ahora también tenemos que entender que generalmente se hacen más de una pieza al mismo tiempo y ambas estarán en producción. El desarrollador podría probar solo su pieza y pensar que está funcionando bien, pero la prueba de regresión general se debe realizar para todas las piezas que se están empujando, así como para descubrir que la combinación de dos piezas diferentes podría interrumpir la aplicación y lo hace. Tampoco se ve bien. 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 la pieza que hicimos es lo que se espera. En general, a pesar de que los requisitos se transfieren a los BA, es posible que la persona final no sepa exactamente cómo se ve y que él / ella piense que no es lo que esperaban o que quieran agregar algo más para que se vea mejor o, por alguna razón, podrían eliminar el pieza entera, ya que piensan que 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 totalidad.

Los comentarios anteriores plantean grandes puntos.

Otro adicional no mencionado anteriormente es que tener un código de prueba individual por 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 con frecuencia la implementación es el resultado de la interpretación de los requisitos por parte de un desarrollador.

Cuando las pruebas se realizan 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 "de acuerdo" proporcionan una confirmación adicional de que el sistema es correcto y realmente coincide con la intención original de los requisitos.

Un programador, al realizar la prueba, verá un cuadro de texto etiquetado como "Cantidad" e ingresará "1". Un programador altamente experimentado hará una prueba de seguimiento con el valor "2".

Un usuario verá un cuadro de texto con la etiqueta "Cantidad" e ingresará "~~ unicorns ROX !!! ~~". Un usuario experimentado también probará "-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 que los desarrolladores también están demasiado cerca de su propio código. Saben que son caprichos, son pequeños comportamientos extraños. Tienden a probar en torno a 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 ejecutan 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 lo probarán mientras se construye la Etapa 2 y se arreglan los defectos de la Etapa 1. Esto se aplica a todas las etapas, por lo que la etapa que se está probando es la anterior que se construyó.

  

Quiero recopilar algunos argumentos sobre por qué permitir que un desarrollador pruebe su propio trabajo como último paso antes de que la prueba comience la producción es una mala idea, porque desafortunadamente, mi lugar de trabajo a veces hace esto (la última vez Esto surgió, el argumento se redujo a que la mayoría de las personas estaban demasiado ocupadas con otras cosas y no tenían 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 logrado con éxito? O bien tiene que escribir algún tipo de pruebas automatizadas (pruebas de unidad) o realizar el trabajo de verificación "es la máquina haciendo lo que quiero que haga" de forma manual (mediante la GUI, llamando al comando en la línea de comandos o lo que sea).

Todo lo que se está probando después 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 está permitido) el código / característica que escribió simplemente no comprenden cómo se está desarrollando el software.

Es probado por alguien que no está familiarizado con el código, te 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 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

Razones por las que podría estar bien que el desarrollador haga la prueba final

• Hay suficiente otra cobertura de prueba ... Existen pruebas de unidad, existe y se usa un entorno de prueba de integración, se han realizado pruebas de IU, pruebas exploratorias, etc. Luego, una prueba final es menos un criterio de aceptación riguroso que un último "recorrido"
• 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 característica / producto / módulo se ha mitigado a niveles bajos (deje que el profesional pruebe las áreas de alto riesgo y que un "novato" pruebe el riesgo más bajo)
• La realidad de la situación empresarial es que lanzar un producto con posibles defectos es mejor que retrasar el lanzamiento
• El desarrollador en cuestión también es en realidad un evaluador muy calificado y es capaz de realizar el cambio de roles mentalmente
• El cambio es una corrección de errores realizada por el desarrollador en el campo cuando el sitio del cliente se cierra o pierde ingresos debido a que el sistema está fuera de línea (un parche que se devolverá a la oficina y se probará / liberará en una versión controlada ASAP)

Razones por las que un desarrollador no debe hacer las pruebas

• Cualquier otra cosa

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

Nota: generalmente estoy a favor de que los Desarrolladores realicen las pruebas, pero me aseguro de que exista el primer punto ...

Los seres humanos, al ser humanos, tienden a sufrir un sesgo cognitivo, 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 tienen una calidad mucho peor.

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

Hay miles de ejemplos por ahí donde 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 aeronaves diferentes ocupen el mismo espacio aéreo. al mismo 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.

• Todo el mundo debería probar: el código de prueba de los desarrolladores, la funcionalidad de la prueba de control de calidad, los mensajes de prueba de marketing. De esa manera, todos comparten las mismas filosofías y el lenguaje en torno a las pruebas, que es la mitad de la batalla.

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

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

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

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

En mi empresa, construimos algunas aplicaciones financieras bastante complejas. Nuestra política general es que el desarrollador debe garantizar que no surjan errores técnicos. Básicamente, intente todo lo que pueda para romperlo, dados los recursos del usuario. Cuando no pueda encontrar un error de tiempo de ejecución, envíelo a los BA para su prueba. Hemos tenido algunos desarrolladores que se perdieron en las pruebas de los requisitos del negocio 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 que reciben un pago para comprender 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 ayudan con los "detalles técnicos" como encontrar ropa del tamaño correcto.

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

Una función de Control 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 comprobación por sí mismo porque si pensaban que habían entendido mal, pedirían una aclaración.