Dejando errores intencionales en el código para que los probadores lo encuentren

Esto suena absolutamente chiflado. Está realizando un gran esfuerzo para obtener un beneficio muy cuestionable, y la práctica parece estar basada en algunas premisas erróneas:

• Ese control de calidad no funcionará a menos que sepan que se están probando todos los días (lo que no puede ser bueno para la moral)

• Que no hay suficientes errores introducidos involuntariamente en el software para que el QA pueda encontrar

• El trabajo de QA es encontrar errores, no lo es; es para garantizar que el software sea de calidad de producción

• Que este tipo de batalla de ingenio entre desarrollo y control de calidad es de alguna manera saludable para la empresa, no lo es; todos los empleados deben trabajar juntos contra los competidores de la empresa en lugar de entre sí.

Es una idea terrible y el gerente del proyecto en cuestión es un imbécil / idiota que no entiende nada acerca de las personas y la motivación. Y es malo para el negocio.

Para ampliar mi descripción de "Trabajo de control de calidad:" El control de calidad debería estar encontrando errores, tanto en el código como en sus suites de prueba, como un artefacto de hacer su trabajo, pero el rol no debe definirse como "usted Hay que encontrar errores ". Debe ser "debe mantener las suites de prueba actualizadas para tener en cuenta las nuevas características y garantizar una alta cobertura de pruebas. Si esto no resulta en la búsqueda de errores, los procedimientos de prueba no son lo suficientemente sofisticados para el producto.

Bueno, basado en lo que he aprendido:

1. No es una escuela ni una entrevista de trabajo;
2. Los evaluadores no son niños;
3. No es un juego;
4. Se desperdicia el dinero de la empresa.

Los QA no están solo para encontrar errores sino también para preocuparse por lo intuitivo que es el sistema, cuál es la curva de aprendizaje para el usuario, facilidad de uso y accesibilidad en general. Por ejemplo: "¿Es el sistema feo ?", "¿Está el usuario ciego y el color es rojo y verde?" También deberían quejarse.

Los requisitos mínimos para que un sistema pase el control de calidad generalmente se describen en una historia de usuario para esa característica en particular o en la forma mágica en que el PO quería que el sistema estuviera en su cabeza.

tl; dr

No solo se trata de errores, los evaluadores deberían crecer fuera de esta visión estrecha.

Mala idea.

Desde el punto de vista del evaluador: "Por lo tanto, realizarán pruebas duras, porque saben que hay errores presentes y que no encontrarlos podría considerarse como su incompetencia". Básicamente, los desarrolladores están atrapando el código. A pocas personas les gusta hacer un trabajo que, en última instancia, no tiene sentido (porque los errores son conocidos de antemano), pero que todavía afectan cómo se perciben. Si hay castigos tangibles por no encontrar las trampas explosivas, más aún. ¿Y sabes que los probadores prosperan en la búsqueda de errores? Eso suena como un ambiente de confrontación tóxico; Un control de calidad debe ser feliz si el código que están examinando es de alta calidad. Aunque si los paga el error ... enlace

Desde el punto de vista del desarrollador: los QAs están siendo incentivados para encontrar los errores que sabes que están ahí. Eso bien puede aumentar la probabilidad de que los errores reales salgan por la puerta; Los QAs pasan al menos parte de su tiempo buscando el tipo de error que es fácil de plantar, no los realmente sutiles. Además, existe una pequeña posibilidad de que una trampa explosiva pueda salir por la puerta.

Estoy totalmente de acuerdo con las respuestas anteriores en cuanto a por qué esto es malo para la motivación y, en general, para una gestión horrible de las personas. Sin embargo, probablemente existen razones técnicas sólidas para no hacer esto también:

  

Justo antes de que el producto pase a control de calidad, el equipo de desarrollo agrega algo intencional   Errores en lugares aleatorios en el código. Ellos respaldan adecuadamente el original,   código de trabajo para asegurarse de que esos errores no se envíen con el final   producto.

1. Según la primera declaración, nunca en realidad prueba el código de producción deseado en estos dos pases.

2. Me imagino que aumenta enormemente la probabilidad de incluir accidentalmente un error "intencional" en su código de producción liberado al intentar acelerar un cambio para un cliente. Puede causar algunas mejillas rojas en algún momento.

3. Me imagino que esto simplemente entrena a tus evaluadores para que piensen como tus desarrolladores (es decir, cómo agregaría un error Tom aquí), lo que probablemente los hace menos propensos a encontrar los errores que Tom no ha pensado.

Editar

Quiero dejar en claro que esta respuesta solo se refiere al concepto de prueba del proceso de control de calidad, y no estoy defendiendo la metodología específica descrita en la pregunta.

Fin de edición

Hay una razón válida para verificar si su prueba / comprobación está funcionando realmente. Déjame darte un ejemplo de fabricación, pero el principio es el mismo.

Es típico cuando se alimenta material a través de una máquina que el alimentador podría no empujar el material lo suficiente. Esto se denomina "alimentación corta" y, para evitarlo, podemos instalar un "sensor de alimentación corta" (generalmente un sensor de tipo de haz pasante que está bloqueado por el material). Este sensor detecta el final del material cuando alcanza la longitud total de alimentación. En cierto punto del ciclo de la máquina, verificamos que el sensor esté bloqueado y detendremos la máquina si falla la comprobación.

Ahora tienes que pensar en cómo la prueba en sí puede fallar. Por ejemplo, alguna suciedad u otros residuos pueden bloquear el sensor y siempre informará "OK" y nunca detendrá la máquina. Además, la naturaleza del sensor es que el receptor se enciende cuando el haz lo golpea, por lo que, dependiendo del tipo de sensor que haya instalado, eléctricamente obtendrá una entrada de "ENCENDIDO" cuando el sensor no esté bloqueado . Eso significa que si el cable se cortó o se perdió la alimentación de ese sensor, o si la entrada falló, la lógica de su programa se leería "OFF" y eso significaría "bloqueado" o "OK".

Para detectar estos modos de falla de la prueba, generalmente insertamos una segunda verificación para asegurarnos de que el sensor esté desbloqueado durante una segunda parte del ciclo. De esta manera, verificamos que la prueba aún esté funcionando (lo mejor que podamos).

Del mismo modo, hay muchas formas en que un departamento de control de calidad puede fallar. Quizás las pruebas automatizadas no se ejecutaron y el informe está revisando una copia antigua de los datos de prueba. Tal vez alguien no está haciendo su trabajo bien. Probar el departamento de control de calidad es algo razonable.

Obviamente, el inconveniente es que un "error de prueba" podría pasar a través del departamento de control de calidad y en el producto terminado. En la industria manufacturera, a veces hay casos en que una parte mala conocida, a veces llamada "Conejo Rojo", se inserta en el proceso (generalmente por alguien de control de calidad) y observan que la parte pasa por el proceso y mide cuánto tiempo lleva encuentra la parte y retírala. Normalmente, esta parte está pintada de rojo brillante (o naranja) para que se pueda rastrear fácilmente. Dado que alguien está viendo el proceso de la pieza durante esta prueba, la probabilidad de que llegue al producto final es prácticamente nula. Hay, por supuesto, historias apócrifas de alguien que arroja una parte mala conocida en el proceso para "ver si el sistema puede encontrarlo", y por supuesto tener que poner en cuarentena todas las partes finales producidas ese día y clasificarlas manualmente, pero eso es simplemente un caso de no realizar su prueba con la debida diligencia.

Honestamente, llamaría a este comportamiento descaradamente poco ético y poco práctico. El PM necesita algún entrenamiento serio, si no su terminación.

• Demuestra una falta de comprensión fundamental del concepto de garantía de calidad . Los evaluadores no deberían pensar como desarrolladores: deberían pensar como usuarios finales. La razón principal para tener equipos de control de calidad es que los desarrolladores están inherentemente demasiado cerca del código; Se supone que el control de calidad debe mantener una distancia suficiente del código para que puedan detectar lo que los desarrolladores no pueden ver.
• Se desperdicia el esfuerzo de control de calidad . Suponiendo que estos errores no son triviales (ver más abajo para cuando lo están) significa que el control de calidad está gastando tiempo y recursos investigando cosas que ya se conocen, cuando podrían estar haciendo ese esfuerzo buscando lo que no se sabe.
• Se desperdicia el esfuerzo del desarrollador . Para que la gente de control de calidad atrape estos errores no triviales, los desarrolladores primero deben escribirlos. Esto requiere un esfuerzo adicional, ya que no solo se deben codificar los errores, sino también los requisitos y el diseño del software.
• Pone la producción en un riesgo innecesario . Es solo cuestión de tiempo antes de que los cambios no se fusionen correctamente.
• Si no hace lo anterior, entonces no tiene sentido . Si todos los errores conocidos son triviales, entonces no atraparán a los trabajadores por debajo del estándar: solo atraparán a las personas que no están haciendo ningún trabajo. Hay mejores formas de hacerlo.
• Envenena el ambiente de trabajo . Sus probadores de control de calidad son profesionales. Se debe confiar en que sea profesional hasta que haya una razón real para sospechar lo contrario. Cuando hay hay razones para sospechar lo contrario, debería haber una investigación adecuada en lugar de estos juegos mentales. Cualquier otra cosa mata la moral.

En serio. Incluso si la paranoia del primer ministro resulta estar bien fundada en este caso específico, esta no es una persona que tenga evaluadores de gestión empresarial.

Personalmente, me siento incómodo con este enfoque.

Lo principal que me preocupa es la posibilidad de insertar errores intencionales . Esto me parece difícil de hacer de cualquier manera que sea predecible.

Cualquier cambio en el código (intencional o no) puede tener efectos secundarios. Estos efectos secundarios pueden revelarse durante las pruebas, pero puede que no sea obvio (incluso para el desarrollador que cometió el error) cuál es la causa principal. No se siente "seguro", si sabes a lo que me refiero (estoy hablando desde mi instinto aquí).

Además, el probador perderá mucho tiempo probando el código que no se lanzará. Una vez que se eliminan los errores intencionales, en mi opinión, debería realizarse una nueva prueba completa de todos modos. Ese es todo el punto de la prueba. Algo cambia, cualquier cosa , y vuelve a probar todo . Ok, sé que eso nunca sucede en la práctica, pero de eso se trata la prueba de regresión.

Entonces, en general, no estoy convencido.

Por otro lado, tendemos a permitir que los clientes verifiquen el trabajo de los equipos de control de calidad, lo que posiblemente no sea ideal. Es un muy poderoso bucle de retroalimentación, sin embargo.

Es una mala idea por todas las razones ya explicadas, pero la selección de errores es una herramienta útil para un propósito diferente. Puede usarlo para obtener una métrica aproximada de cuán efectivo es el proceso de control de calidad.

En su caso más simple, digamos que siembras 100 errores y son representativos del rango completo de errores reales (lo sé, es poco probable, pero estoy simplificando). No le dices a QA que estás haciendo esto para evitar estropear el experimento. Al final del proceso de control de calidad digamos que encontraron 60 de los 100 errores sembrados (y otros errores reales). Ahora sabes que el control de calidad está encontrando el 60% de los errores.

Puede extender esto más allá contando el número de QA reales encontrados y aplique la proporción de errores falsos. En nuestro ejemplo, si el control de calidad encontró 200 errores reales, puede concluir que solo encontraron el 60% de ellos, por lo que quedan 133.

Por supuesto, esto es solo una estimación amplia con enormes barras de error. Escribir errores realistas y representativos es difícil. Es probable que los errores que escribas sean más fáciles para que el QA los encuentre porque los desarrolladores están entrenados para no escribir errores. Puede ser mejor simular una clase de errores, como los errores off-by-one, los errores de Unicode, los desbordamientos de búfer, etc.

Esto debería aplicarse a todo el proceso de QA , que incluiría pruebas de unidad de desarrollador, integración continua y, si está disponible, un equipo de QA dedicado.

Esta es una métrica , y no debe ser secuestrada como una herramienta de motivación de gestión.

Mala idea.

Este es el tipo de enfoque lógico y binario que los desarrolladores suelen ofrecer, pero es desmotivador para los QE. Simplemente demuestra una falta de confianza. Las QE a menudo se colocan en estas situaciones sin mucha información de ellas, y se supone que están de acuerdo con ellas, y no es su lugar sugerir lo contrario.

Este tipo de pensamiento se combina para que las QE sean solo evaluadores manuales y no estén motivados para entender el código real que se está probando.

Soy un QE senior y este es un problema familiar en la mayoría de las organizaciones en las que he trabajado.

Yo diría mala idea.

Uno: los programadores pasarán tiempo poniendo errores deliberados en el código y harán un esfuerzo para salvar la buena versión. Mientras que los probadores probablemente deberían estar probando todo, incluidas las características con el error plantado, cuando encuentren uno, probablemente tendrán que volver atrás y volver a ejecutar esa prueba para verificar que esto fue realmente un error (y no que el probador se haya confundido). de alguna manera). Como mínimo, los evaluadores pasarán tiempo escribiendo los errores plantados. Luego los programadores tienen que dedicar tiempo a corregir el error que plantaron. Esto es un gran esfuerzo que se podría gastar intentando escribir un buen código y escribir errores reales.

Dos: envía un mensaje claro a los evaluadores de que los programadores y / o la administración piensan que no están haciendo su trabajo y deben ser tratados como niños. No puedo imaginar que esto sea bueno para la moral. Como programador, si me dieron especificaciones ambiguas o contradictorias para un programa y tuve que pasar un montón de tiempo para aclararlas, y luego, después de perder horas o días, mi jefe me dijo: "Oh, sí, puse deliberadamente declaraciones contradictorias en las especificaciones solo para asegurarse de que realmente las estabas leyendo ", creo que estaría realmente molesto. Si eso ocurriera regularmente, eso podría ser suficiente para hacerme buscar otro trabajo.

En la vida real, todos los cambios de código, excepto los más triviales, tendrán errores. Nunca he tenido un problema con los probadores que se vuelven complacientes porque el primer borrador de código que se les dio a menudo era 100% perfecto. Tuve que lidiar con probadores perezosos que no hacen un trabajo adecuado, pero no lo hicieron porque los programadores eran tan perfectos. La mejor persona de pruebas con la que he trabajado una vez me dijo que para un nuevo lanzamiento de software, se fijó un objetivo personal para encontrar 100 errores. De acuerdo, si 100 es un número realista depende de qué tan grande es el producto y cuán extensos son los cambios, pero en nuestro caso, casi siempre logró alcanzar ese objetivo. A veces tenía que estirar las cosas, como llamar "error" a una palabra mal escrita en un mensaje, pero bueno, tenía que arreglarse.

Publicar script: si haces esto, apuesto a que tarde o temprano los programadores plantarán deliberadamente un error, los evaluadores no encontrarán ese problema en particular y los programadores se olvidarán de devolver el código correcto. Así que ahora un error plantado deliberadamente se envía al cliente.

Realmente no creo que esto sea una idea mala . Hay muchas cosas que especularía que funcionen mejor:

1. Haga que el control de calidad sea responsable de la calidad de la manera que pueda. Por ejemplo, haciendo que el apoyo sea su responsabilidad también. Esto aumentará su motivación para asegurarse de que los productos enviados tengan mayor calidad. Siempre se requiere menos esfuerzo para descubrir una insuficiencia (error, característica obviamente faltante, comportamiento contraintuitivo) y luego tratar de entender lo que el usuario molesto está tratando de explicar. Y poner algo de esa responsabilidad incluso en los desarrolladores podría aumentar su motivación para ayudar al QA a hacer su trabajo lo mejor que puedan.

2. Tenga varios equipos de control de calidad, que pueden competir. Necesitas encontrar una métrica sensible por supuesto. Definitivamente no solo el número de cuestiones. El factorizar la gravedad del defecto o el valor comercial (según lo determinen los interesados) de las mejoras propuestas debería ayudar.

Es difícil decir si el control de calidad es "lo suficientemente bueno". A la larga, es más fácil y, posiblemente, incluso mejor encontrar formas para que el control de calidad pueda "mejorar".

Sin embargo, hay un problema que debes tener en cuenta si introduces errores intencionales: ¿Cómo sabes que el código "correcto" alguna vez fue correcto en primer lugar? Después del segundo control de calidad, eliminas todo errores intencionales que no habían sido descubiertos. No hay forma de saber que no está simplemente reemplazándolos por un código que está roto de otra manera o que no está habilitando un comportamiento roto que antes era inalcanzable (ejemplo exagerado: algunos cuadros de diálogo no se abrieron debido a un error intencional, pero el diálogo en sí está roto, simplemente no lo averiguas porque los evaluadores no pudieron verlo).

Como han dicho otros, los desarrolladores no deberían agregar errores a propósito en el software, pero es una estrategia legítima para su conjunto de pruebas para agregar errores en el software como parte del proceso de prueba.

Se llama prueba de mutación . La idea es usar software para automatizar la creación de pequeños cambios en el código fuente (llamados mutantes). Los cambios están diseñados para crear un comportamiento diferente, por ejemplo, podríamos cambiar

if x < 10:
    print "X is small!"

en

# we flipped the inequality operator
if x > 10:
    print "X is small!"

y una buena prueba unitaria debería detectar que el fragmento del código mutante ya no funciona como se esperaba y mata al mutante . Cuando el código original pasa la prueba y todos los mutantes (que no son funcionalmente equivalentes) fallan en la prueba, entonces sabes que tu código y tus pruebas son fuertes .

Me gusta la idea. ¿Fue el general Patton quien dijo: "Mientras más sudas en paz, menos sangras en la guerra".

Poner errores intencionales "desperdicia tiempo" de los evaluadores. Pero eso también hace que trabajen más duro, lo que significa que también harán un mejor trabajo para encontrar errores no intencionales. (Y tiene una copia del "original", por lo que no tiene que vivir con lo que ha hecho).

Encontrar más errores involuntarios probablemente le ahorrará más dolor a largo plazo que el costo de tratar con los intencionales.

Además, puede tener una idea de lo buenos que son sus evaluadores, no un pequeño beneficio en sí mismo.

No hay ninguna base para una recompensa o un castigo por su propio mérito, sino en el resultado del comportamiento al que te diriges. Y a veces hay consecuencias involuntarias. El objetivo es evitar que el equipo de control de calidad se afloje o hacer que un gerente sienta que realmente está contribuyendo con algo sin darse cuenta de que solo se está interponiendo en el camino.

Resultado positivo: el equipo de control de calidad trabaja más duro para encontrar errores. Quién sabe, tal vez vean esto como un desafío. Es un juego amistoso. O simplemente lo están haciendo porque están siendo observados (¿Efecto Hawthorne?).

Resultado negativo: es posible que no trabajen más y que encuentren el error de todos modos. QA ve esto como mezquino y contradictorio. Así que ahora, entran en la búsqueda de errores y devuelven todo tipo de pequeños problemas. Esa fuente no se representa correctamente cuando tomo una captura de pantalla, la convierto en un pdf y la veo al 500%.

Sin impacto: el sonido para mí no hace ninguna diferencia, así que, ¿para qué molestarse? Solo te arriesgas a perder el tiempo e irrita a las personas.

Todos podríamos estar de acuerdo en que esto no funcionará el 90% del tiempo. Eso no hace mucho bien al otro 10%. Prueba las cosas por ti mismo. ¿Están los clientes más satisfechos con una versión que tiene los errores de código intencional? ¿Afecta la moral de los trabajadores y la productividad en otras áreas? Aumentar la facturación? Usted nos dice.

Procedentes de un mundo en el que se espera que los desarrolladores escriban y ejecuten las pruebas por sí mismos, este silo "QA" de "prueba" al que se refiere se asusta y me confunde, así que intentaré responder desde esta perspectiva. Además, desde mi punto de vista, los ingenieros de control de calidad calificados (como se describe bien en la respuesta de @ SparK), deberían centrarse en los problemas más importantes de asegurarse de que el software satisface plenamente las historias de los usuarios y tiene una "calidad" general (con respecto a el dominio al que está destinado el software), en lugar de buscar errores.

Lo que me atrajo aquí es la mención de @ JamesMcleod de "inyección defectuosa" en los comentarios a la pregunta. De hecho, creo que hacer que los desarrolladores piensen cómo podrían inyectar errores en el sistema es una gran idea para enfocar el concepto de defensa en profundidad. Ningún error debe ser suficiente para derribar todo el sistema de forma incontrolada (sin un registro de acciones que pueda realizarse), causar daños a los datos o, por sí solo, exponer una vulnerabilidad de seguridad.

Si los desarrolladores de cada componente crean defectos intencionales, manejan los de otros componentes y, en general, adoptan una mentalidad más adversa acerca de su software, podría hacer mucho para mejorar la robustez del software. Incluso el beneficio inmediato podría ser significativo: requeriría que durante cada inyección de este tipo de un nuevo tipo de defecto (que hasta ahora no se había probado), el desarrollador lo cubriera de inmediato con una nueva prueba, que se establecerá con una marca que Permita que el error viva en el código base sin ser perturbado por un corto tiempo, y luego se encienda antes de la entrega (y se elimine el defecto), para que se convierta en una prueba regular que haga que el conjunto de pruebas sea más completo.

Una opción relacionada es el uso de indicadores de características para desactivar intencionalmente las características en componentes particulares para examinar cómo otros componentes tratan eso. También me gustaría recomendar encarecidamente leer el libro / artículo gratuito "Aprendiendo de los primeros respondedores : Cuando sus sistemas tienen que funcionar " que describe pruebas tan extensas de la infraestructura de software que utilizará el equipo de Obama para las elecciones de 2012.

Como ya han dicho otros, no es el trabajo de QA solo encontrar errores. Iría más allá y diría que técnicamente no es su trabajo. Los desarrolladores deben ser responsables de mantener su propio código libre de errores. Las suites de prueba deben ejecutarse antes de que el nuevo código sea confirmado, y si las suites de prueba fallan, entonces, en primer lugar, nunca debe estar en control de calidad. La introducción de errores intencionalmente significa que definitivamente no puedes pasar tus suites de prueba, ¿por qué tu código va a QA?

El trabajo de QA es validar la aplicación contra las historias de usuario que implementa. Deben probar el flujo, la interfaz de usuario, etc. y asegurarse de que el usuario pueda hacer todo lo que el usuario debería hacer, de la manera más fácil y accesible posible. Mientras hacen esto, por supuesto, pueden tropezar con errores, pero eso es un efecto secundario de lo que hacen, no de lo que hacen. Recuerde que el control de calidad significa la garantía de calidad, no la garantía libre de errores.

Esto no es necesariamente tan loco como suena. Depende más bien de tu motivación. Si está buscando un palo para vencer a su equipo de prueba, bueno, sería una locura. Por otro lado, una de las cosas más difíciles en el desarrollo de software es saber qué tan efectivo es su enfoque de prueba.

Entonces, si lo estructura correctamente, puede usar esta técnica para estimar cuántos errores no encontrados quedan en el producto que está a punto de enviar. Entonces imagine que ha sembrado artificialmente 100 errores en su compilación de prueba, y los evaluadores encuentran 50 de ellos. Luego, puede inferir que existe una cierta probabilidad de que si también encuentran 50 errores no sembrados, quizás queden 50 por encontrar.

Por supuesto, esto está lleno de muchos problemas. Puede decidir si realizar el envío según estas estadísticas, pero en la vida real, puede encontrar un problema muy desagradable, o mil irritaciones menores.

Aún: el conocimiento es poder, y sin esta técnica, tiene aún menos idea de la calidad de su código base. Si puedes implementarlo respetuosamente y por las razones correctas, diría "¿Por qué no?"

Una cosa que nadie más ha mencionado todavía: prueba de mutación .

Aquí es donde una herramienta automatizada toma su código fuente y lo inserta deliberadamente. (Por ejemplo, elimine una declaración elegida al azar, cambie un AND a un OR, o lo que sea). A continuación, ejecuta su conjunto de pruebas completo y comprueba si las pruebas pasan.

Si todas las pruebas pasan, hay dos posibilidades:

• Lo que se cambió no hace nada. En otras palabras, usted tiene un código muerto.
• El cambio introdujo un error que su conjunto de pruebas no está detectando. Necesitas más pruebas.

Tenga en cuenta que, a diferencia de su propuesta, todo lo que he descrito anteriormente es automatizado . No estás perdiendo el tiempo de los desarrolladores insertando errores inútiles a mano. Y no estás perdiendo el tiempo de los probadores encontrando errores conocidos. Lo único que estás usando es el tiempo de la máquina, que es mucho más barato. (Las máquinas no se aburren de hacer la misma prueba 20,000 veces. ¡Los humanos dejan de preocuparse después de un tiempo!)

Sugeriría que las pruebas automatizadas de mutación son un enfoque mucho mejor que el escenario manual del que estás hablando.

Tenga en cuenta que si le pide a un desarrollador que inserte errores manualmente, es probable que el tipo de error que recibe no sea representativo del tipo de errores accidentales que los humanos pueden cometer. (Por ejemplo, si no te has dado cuenta de que existe una posible condición de carrera, tampoco es probable que inserte una deliberada). Si queda claro que una herramienta automatizada puede ser más objetiva, por supuesto ...

Aunque es una mala idea en general (las otras respuestas explican perfectamente por qué), hay una situación especial en la que intencionalmente inyectar errores en el código de producción de manera controlada y temporal puede tener sentido.

Cuando refactoriza el código de prueba (y debería hacerlo, el código de prueba merece la misma atención a los detalles que el código de producción) es posible que desee saber si el código de prueba sigue encontrando los errores que se supone que debe encontrar.

Luego, puede romper intencionalmente el código de producción para verificar si las pruebas aún funcionan.

Hay varios niveles en los que esto es posible:

• Un desarrollador que acaba de reformular algunas pruebas unitarias podría romper el código de producción para verificar que la prueba unitaria aún encuentre lo que se supone que debe encontrar.
• Un probador que acaba de reformular algunas pruebas de aceptación podría romper el código de producción para verificar que la prueba de aceptación aún verifique lo que se supone que debe verificar.
• Si la interfaz es lo suficientemente estable y robusta (es decir, basada en el protocolo), la compañía podría querer mantener un conjunto de versiones de productos defectuosos conocidos y realizar pruebas contra ellos para realizar una prueba de regresión.

Si estas cosas tienen sentido depende. Si soy un desarrollador y me toma solo un minuto inyectar un error, probar la prueba de la unidad, eliminar el error, entonces ¿por qué no? Pero debería tener mi editor, mi ciclo y mi sistema de control de versiones bajo un control tan bueno que accidentalmente no cometería / entregaría / registraría / empujaría el error. Lo mismo ocurre con el probador y la prueba de aceptación.

Si tiene sentido para una organización mantener conjuntos de versiones de productos defectuosos conocidos y pruebas de regresión, la prueba depende. Para una tienda online no lo haría. Para automóviles integrados, aeroespaciales, tarjetas bancarias o tarjetas de TV de pago, lo haría.

El esfuerzo que esto supone depende en gran medida de la manera en que se desacoplan las pruebas del código de producción. Cuanto más desacopladas estén las pruebas del código de producción, cuanto menor sea el esfuerzo por hacer esto, cuanto más cohesionadas estén las pruebas con el código de producción, mayor será el esfuerzo.

El motivo es simplemente este: cuando sus pruebas y su código de producción son coherentes, cambiar el código de producción requiere cambiar las pruebas con frecuencia, y eso rompería la dependencia entre las pruebas y las muestras de producción defectuosas. Entonces tendría que mantener también las muestras de producción defectuosas. En casos excepcionales, incluso eso puede valer la pena, y el burlarse y el uso inteligente de un sistema de control de versiones pueden reducir significativamente el esfuerzo, pero requiere que los desarrolladores estén muy por encima de ellos.

El concepto de inyectar fallas intencionalmente en el código de producción se llama sabotage , la falla inyectada se llama saboteur .

Un probador que no está tomando el código para ser probado directamente desde el repositorio lo está haciendo mal. (1)

Un desarrollador que está registrando el código conocido-defectuoso en el repositorio lo está haciendo mal. (2)

Por lo tanto, en esta etapa, ya no hay forma de que este esquema funcione sin que una o ambas partes violen las premisas muy básicas de cómo se debe realizar el desarrollo y las pruebas.

(1) Porque necesita documentar qué versión probó. Una versión etiquetada por un hash de Git o un número de revisión de SVN es algo que puede probar, "el código que me dio Joe" no lo es.

(2) Porque simplemente no lo hace, fuera de un controlador de prueba que está esperando error.

Este es un intento por una razón de "lanzamiento de ascensor" lo más breve posible que debería tener un sentido inmediato para desarrolladores, probadores y administradores por igual.

Recomiendo no inyectar errores deliberadamente en CADA compilación que envíe a QA.

Podrías, de vez en cuando, digamos una vez al año, hacer una "auditoría de control de calidad" encubierta. Tome un código base "probado y en funcionamiento", y tantas nuevas funciones pequeñas de su lista de tareas como sea posible. Implementarlos "un poco más descuidadamente" de lo que normalmente haces. Piense en los casos de borde, escríbalos, pero no arregle su código para tenerlos en cuenta. Envíelo a QA.

Si encuentran más errores de casos que no funcionan correctamente de lo que escribiste, ciertamente no es tu control de calidad el que necesita supervisión ... ;-)