Dejar errores intencionales en el código para que los evaluadores los encuentren

No hacemos esto en nuestra empresa, pero uno de mis amigos dice que su gerente de proyecto le pidió a cada desarrollador que agregue errores intencionales justo antes de que el producto pase al control de calidad. Así es como funciona:

1. Justo antes de que el producto pase al control de calidad, el equipo de desarrollo agrega algunos errores intencionales en lugares aleatorios del código. Realizan una copia de seguridad del código de trabajo original para asegurarse de que esos errores no se envíen con el producto final.
2. Los probadores también están informados sobre esto. Por lo tanto, se pondrán a prueba, porque saben que hay errores presentes y que no encontrarlos podría considerarse como un signo de incompetencia.
3. Si se ha encontrado un error (intencional o no), se informará al equipo de desarrollo para que lo repare. Luego, el equipo de desarrollo agrega otro error intencional en una sección relacionada del código justo antes de que el producto pase al control de calidad de segundo nivel. El gerente del proyecto dice que un evaluador debe pensar como un desarrollador y que debe esperar nuevos errores en las secciones donde se realizaron los cambios.

Bueno, así es como va. Dicen que este enfoque tiene las siguientes ventajas.

1. Los probadores siempre estarán alerta y probarán como locos. Eso les ayuda a encontrar también errores ocultos (no intencionales) para que los desarrolladores puedan solucionarlos.
2. Los probadores se alimentan de errores. No encontrar ningún error afectará su moral. Entonces, darles uno fácil de encontrar ayudará a su moral.

Si ignora el escenario en el que uno de estos errores intencionales se envía con el producto final, ¿cuáles son los otros inconvenientes que debemos considerar antes de siquiera pensar en adoptar este enfoque?

Algunas aclaraciones:

1. Realizan una copia de seguridad del código original en el control de origen.
2. Cuando un probador encuentra el error intencional, el equipo de desarrollo simplemente lo ignora. Si el probador descubre un error involuntario (original), el equipo de desarrollo primero verifica si es causado por alguno de los errores intencionales. Es decir, el equipo de desarrollo primero intenta reproducir eso en el código de trabajo original e intenta arreglarlo si puede.
3. Simplemente ignore los problemas de relación entre el control de calidad y el equipo de desarrollo. Hice esta pregunta específicamente en Programadores , no en The Workplace . Tenga en cuenta que existe una buena relación entre el control de calidad y el equipo de desarrollo, y se divierten juntos después del horario laboral. El gerente del proyecto es un buen caballero que siempre está listo para apoyar a ambos equipos (Godsend).

Esto suena absolutamente loco. Está gastando un gran esfuerzo para obtener beneficios muy cuestionables, y la práctica parece basarse en algunas premisas defectuosas:

• 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 QA encuentre

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

• Que este tipo de batalla de ingenio entre el desarrollo y el 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 compañía en lugar de entre sí.

Es una idea terrible y el gerente de 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 los negocios.

Para ampliar mi descripción del "trabajo de QA:" QA definitivamente debería encontrar 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 "tienes que encontrar loco." Debe ser "debe mantener las suites de prueba actualizadas para tener en cuenta las nuevas funciones y garantizar una alta cobertura de las 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 aprendí:

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

El control de calidad no solo está ahí 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, la usabilidad y la accesibilidad en general. Por ejemplo: "¿El sistema es feo ?", "¿El usuario es daltónico y las cosas son rojas y verdes?" Deberían quejarse también.

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 qué tan mágico el PO quería que el sistema estuviera en su cabeza.

tl; dr

No se trata solo de errores, los evaluadores deberían salir de esta visión limitada.

Mala idea.

Desde el punto de vista del probador: "Por lo tanto, realizarán una prueba dura, porque saben que hay errores presentes y 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 se conocen de antemano) pero que aún 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 QA debería ser feliz si el código que están examinando es de alta calidad. Aunque si son pagados por el error ... http://thedailywtf.com/articles/The-Defect-Black-Market

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

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

Justo antes de que el producto pase al control de calidad, el equipo de desarrollo agrega algunos errores intencionales en lugares aleatorios del código. Realizan una copia de seguridad del código de trabajo original para asegurarse de que esos errores no se envíen con el producto final.

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

2. Me imagino que aumenta enormemente la probabilidad de incluir accidentalmente un error 'intencional' en su código de producción publicado cuando intenta acelerar un cambio para un cliente. Podría causar algunas mejillas rojas en algún momento.

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

Editar

Quiero dejar claro que esta respuesta solo habla sobre el concepto de probar su proceso de control de calidad, y no estoy defendiendo la metodología específica presentada en la pregunta.

Fin de edición

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

Al alimentar material a través de una máquina, es típico que el alimentador no empuje el material lo suficiente. Esto se denomina "alimentación corta" y, para evitarlo, podríamos instalar un "sensor de alimentación corta" (generalmente, un sensor de tipo de haz continuo que está bloqueado por el material). Este sensor detecta el final del material cuando alcanza la longitud de alimentación completa. En cierto punto del ciclo de la máquina, verificamos que el sensor esté bloqueado y detenemos la máquina si la verificación falla.

Ahora debe pensar en cómo la prueba en sí puede fallar. Por ejemplo, algo de suciedad u otros desechos 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 rayo 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 energía de ese sensor, o la entrada falló, la lógica de su programa leería "OFF" y eso significaría "bloqueado" u "OK".

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

Del mismo modo, hay muchas formas en que un departamento de control de calidad puede fallar. Tal vez las pruebas automatizadas no se ejecutaron y el informe está mirando una copia antigua de los datos de la prueba. Quizás alguien no está haciendo bien su trabajo. 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 llegar al producto terminado. En la industria manufacturera, a veces hay casos en los que una parte defectuosa conocida, a veces llamada "Conejo Rojo", se inserta en el proceso (generalmente por alguien de QA) y observan que esa parte pasa por el proceso y miden cuánto tiempo lleva encuentra la pieza y quítala. Normalmente esta parte está pintada de rojo brillante (o naranja) para que pueda rastrearse fácilmente. Dado que alguien está viendo el proceso de la pieza durante esta prueba, la posibilidad de que llegue al producto final es prácticamente nula. Hay, por supuesto, historias apócrifas de alguien lanzando una parte mala conocida en el proceso para "ver si el sistema puede encontrarla",

Honestamente, llamaría a este comportamiento descaradamente poco ético y poco práctico. El primer ministro necesita una nueva capacitación seria, si no una terminación.

• Demuestra una falta fundamental de comprensión del concepto de garantía de calidad . Los probadores no deberían pensar como desarrolladores: deberían pensar como usuarios finales. La razón completa para tener equipos de control de calidad es que los desarrolladores son intrínsecamente demasiado cercanos al código; Se supone que el control de calidad mantiene una distancia suficiente del código para que puedan captar lo que los desarrolladores pierden.
• Se desperdicia el esfuerzo de control de calidad . Asumir que estos errores no son triviales, ver a continuación cuándo lo son, significa que el control de calidad está gastando tiempo y recursos investigando cosas que ya se conocen, cuando podrían estar gastando ese esfuerzo buscando lo que no se sabe.
• Se desperdicia el esfuerzo del desarrollador . Para que la gente de QA detecte estos errores no triviales, los desarrolladores primero deben escribirlos. Esto requiere aún más esfuerzo, no solo para codificar los errores, sino también para considerar 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 de calidad inferior: solo atraparán a las personas que no están trabajando en absoluto. Hay mejores formas de hacerlo.
• Envenena el ambiente de trabajo . Sus evaluadores de control de calidad son profesionales. Se debe confiar en que sean profesionales hasta que haya una razón real para sospechar lo contrario. Cuando no es razón para sospechar lo contrario, debe haber una investigación adecuada en lugar de estos juegos de la mente. Cualquier otra cosa mata la moral.

Seriamente. Incluso si la paranoia del primer ministro resulta estar bien fundada en este caso específico, no se trata de alguien que tenga probadores de gestión empresarial.

Personalmente, me siento incómodo con este enfoque.

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

Cualquier cambio en el código (intencional o no) corre el riesgo de tener efectos secundarios. Es posible que estos efectos secundarios se revelen durante las pruebas, pero puede que no sea obvio (incluso para el desarrollador que plantó el error) cuál es la causa raíz. No se siente "seguro", si sabes a lo que me refiero (estoy hablando desde aquí).

Además, el probador perderá mucho tiempo probando el código que en realidad no se lanzará. Una vez que se eliminan los errores intencionales, en mi opinión, se debe hacer una nueva prueba completa de todos modos. Ese es el objetivo de las pruebas. Algo cambia, cualquier cosa , y vuelves 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 lo ideal. Sin embargo, es un circuito de retroalimentación muy poderoso.

Es una mala idea por todas las razones ya dadas, pero la generació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 de la gama completa de errores reales (lo sé, poco probable, pero estoy simplificando). No le dice a QA que está 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 sabe que el control de calidad está encontrando el 60% de los errores.

Puede ampliar esto aún más contando el número de errores reales que QA encontró y aplicar la proporción de errores falsos. En nuestro ejemplo, si QA 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 escriba sean más fáciles de encontrar para el control de calidad porque los desarrolladores están capacitados para no escribir errores. Puede ser mejor simular una clase de errores tales como errores off-by-one, errores Unicode, desbordamientos de búfer, etc.

Esto debe aplicarse a todo el proceso de control de calidad que incluiría pruebas de la unidad de desarrollo, integración continua y, si está disponible, un equipo de control de calidad dedicado.

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

Mala idea.

Este es el tipo de enfoque lógico y binario que los desarrolladores suelen ofrecer, pero desmotiva a los QE. Simplemente demuestra una falta de confianza. Los QE a menudo se colocan en estas situaciones sin mucho aporte de ellos, y se supone que están de acuerdo, y no es su lugar sugerir lo contrario.

Este tipo de pensamiento se combina con que los QE son solo probadores manuales y no están motivados para comprender el código real bajo prueba.

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 que es una mala idea.

Uno: los programadores van a pasar tiempo poniendo errores deliberados en el código, y algo de esfuerzo para guardar la buena versión. Si bien es probable que los probadores estén probando todo, incluidas las características con el error plantado, cuando encuentren uno probablemente tendrán que volver y volver a ejecutar esa prueba para verificar que realmente se trata de 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 pasar tiempo arreglando el error que plantaron. Este es un gran esfuerzo que podría gastarse tratando de 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 gerencia 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 mucho tiempo para aclararlas, y luego, después de perder horas o días, mi jefe me dijo: "Oh, sí, deliberadamente puse declaraciones contradictorias en las especificaciones solo para asegurarte de que realmente las estabas leyendo ", creo que estaría realmente molesto. Si eso sucediera regularmente, eso podría ser suficiente para hacerme buscar otro trabajo.

En la vida real, todos los cambios de código menos los más triviales TENDRÁN errores. Nunca tuve un problema con los probadores que se volvieron complacientes porque el primer borrador del código que les dieron a menudo era 100% perfecto. Tuve que lidiar con probadores perezosos que no hacen un trabajo adecuado, pero no lo lograron porque los programadores eran tan perfectos. La mejor persona de pruebas con la que trabajé una vez me dijo que para una nueva versión de software, se propuso un objetivo personal para encontrar 100 errores. De acuerdo, si 100 es un número realista depende de cuán grande sea el producto y cuán extensos sean los cambios, pero en nuestro caso, casi siempre logró cumplir 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 solucionarlo.

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

Realmente no creo que sea una mala idea. Solo hay muchas cosas que especularía que funcionan mejor:

1. Haga que QA sea responsable de la calidad de cualquier manera que pueda. Por ejemplo haciendo apoyo también su responsabilidad. Esto aumentará su motivación para asegurarse de que los productos enviados tengan una mayor calidad. Siempre se necesita menos esfuerzo para descubrir una inadecuación (error, característica que obviamente falta, comportamiento contraintuitivo) y luego tratar de comprender lo que su usuario molesto está tratando de explicar. Y poner parte 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. Tener múltiples equipos de control de calidad, que pueden competir. Necesitas encontrar una métrica sensata, por supuesto. Definitivamente no solo la cantidad de problemas. Debería ser útil tener en cuenta la gravedad del defecto o el valor comercial (según lo determinado por las partes interesadas) de las mejoras propuestas.

Es difícil saber si el control de calidad es "suficientemente bueno". Es más fácil y posiblemente incluso mejor a largo plazo encontrar formas para que el control de calidad esté "mejorando".

Sin embargo, hay un problema que debe tener en cuenta si introduce errores intencionales: ¿cómo sabe que el código "correcto" alguna vez fue correcto en primer lugar? Después del segundo control de calidad, eliminas todos los errores intencionales que no se habían descubierto. No hay forma de saber que no estás simplemente reemplazándolos por código que está roto de una manera diferente o que no estás habilitando un comportamiento roto que antes era inalcanzable (ejemplo exagerado: algunos diálogos no se abrieron debido a un error intencional, pero el diálogo en sí está roto, simplemente no lo descubres porque los probadores no pudieron verlo).

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

Se llama prueba de mutación . La idea es utilizar 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 diferentes comportamientos, por ejemplo, podríamos cambiar

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

dentro

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

y una buena prueba de unidad debería detectar que el fragmento de 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 la prueba, entonces sabes que tu código y tus pruebas son fuertes .

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

Poner errores intencionales "desperdicia el tiempo" de los probadores. Pero eso también los hace trabajar 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" para que no tenga que vivir con lo que ha hecho).

Encontrar más errores no intencionales 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 base para una recompensa o castigo por mérito propio, sino por el resultado del comportamiento al que se dirige. Y a veces hay consecuencias no deseadas. El objetivo es evitar que el equipo de control de calidad se afloje o hacer que algún gerente sienta que realmente está contribuyendo algo sin darse cuenta de que solo se está interponiendo en el camino.

Resultado positivo: el equipo de control de calidad trabaja más para encontrar errores. Quién sabe, quizás 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 encuentren el error de todos modos. QA ve esto como algo mezquino y conflictivo. Entonces, ahora entran en la búsqueda de hiperbugs y devuelven todo tipo de pequeños problemas quisquillosos. Esa fuente no se procesa correctamente cuando tomo una captura de pantalla y la convierto a PDF y la veo al 500%.

Sin impacto: el sonido para mí no hace ninguna diferencia, entonces, ¿por qué molestarse? Corres el riesgo de perder el tiempo e irritar a las personas.

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

Viniendo de un mundo donde se espera que los desarrolladores escriban y ejecuten las pruebas ellos mismos, este silo de "prueba" "QA" al que te refieres me asusta y me confunde, así que intentaré responder desde esta perspectiva. Por otro lado, los ingenieros de control de calidad calificados, desde mi perspectiva, (como se describe bien en la respuesta de @ SparK), deberían centrarse en los problemas más importantes de asegurarse de que el software satisfaga completamente las historias de los usuarios y tenga una "calidad" general (en lo que respecta a el dominio para el que está destinado el software), en lugar de buscar errores.

Lo que me atrajo aquí es la mención de @ JamesMcleod de "inyección de defectos" 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 manera incontrolada (sin un registro claro y procesable), causar daños en los datos o exponer por sí solo una vulnerabilidad de seguridad.

Hacer que los desarrolladores de cada componente creen defectos intencionales, manejen los de otros componentes y, en general, entren en una mentalidad más conflictiva sobre su software, posiblemente 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 un nuevo tipo de defecto (que hasta ahora no se había probado), el desarrollador lo cubriría de inmediato con una nueva prueba, que se establecerá con un indicador que permita que el error viva en la base del código sin interrupciones por un corto tiempo, y luego enciéndalo antes de la entrega (y elimine el defecto), para convertirlo en una prueba regular que hará que el conjunto de pruebas sea más completo.

Una opción relacionada es el uso de indicadores de característica para desactivar intencionalmente las características en componentes particulares para examinar cómo otros componentes lidian con 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 control de calidad encontrar únicamente errores. Yo iría más lejos y diría que no es su trabajo, técnicamente. Los desarrolladores deben ser responsables de mantener su propio código libre de errores. Las suites de prueba deben ejecutarse antes de que se confirme el nuevo código, y si las suites de prueba fallan, en primer lugar, nunca debería llegar a QA. Introducir errores intencionalmente significa que definitivamente no puede pasar sus conjuntos de pruebas, entonces, ¿por qué su 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 poder hacer, de la manera más usable y accesible posible. Al hacer esto, por supuesto, pueden tropezar con errores, pero eso es un efecto secundario de lo que hacen, no de lo que hacen. Recuerde que QA significa Garantía de calidad, no Garantía sin errores.

Esto no es necesariamente tan loco como parece. Más bien depende de tu motivación. Si está buscando un palo para vencer a su equipo de prueba, eso 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, podría usar esta técnica para estimar cuántos errores no encontrados quedan en el producto que está a punto de enviar. Así que imagina que has sembrado artificialmente 100 errores en tu versión de prueba, y los evaluadores encuentran 50 de ellos. Entonces puede inferir que existe una cierta probabilidad de que si también encontraron 50 errores no sembrados, tal vez quedan 50 por encontrar.

Por supuesto, esto está plagado de muchos problemas. Podrías decidir si enviar según estas estadísticas, pero en la vida real, puedes encontrar un problema muy desagradable o mil irritaciones menores.

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

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

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

Si todas las pruebas pasan, entonces hay dos posibilidades:

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

Tenga en cuenta que, a diferencia de su propuesta, todo lo que describí anteriormente está automatizado . No está desperdiciando el tiempo de los desarrolladores insertando errores sin sentido a mano. Y no está desperdiciando el tiempo de los evaluadores para encontrar 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 de mutación automatizadas son un enfoque mucho, 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, el tipo de error que obtiene probablemente no sea representativo del tipo de errores accidentales que pueden cometer los humanos. (Por ejemplo, si no se ha dado cuenta de que existe una posible condición de carrera, tampoco es probable que inserte una deliberada). Por supuesto, queda por ver si una herramienta automatizada logra ser más objetiva ...

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

Cuando refactorice el código de prueba, y debería hacerlo, el código de prueba merece la misma atención al detalle que el código de producción, es posible que desee saber si el código de prueba todavía está 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 refactorizar alguna prueba unitaria podría romper el código de producción para verificar que la prueba unitaria todavía encuentre lo que se supone que debe encontrar.
• Un probador que acaba de refactorizar alguna prueba 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 ejecutar pruebas en contra de ellos para probar la prueba de regresión.

Si estas cosas tienen sentido depende. Si soy 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 no cometería accidentalmente / entregue / registre / presione 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 en línea no lo haría. Para las tarjetas bancarias o tarjetas de televisión de pago integradas para automoción, aeroespacial, embebidas, lo haría.

La cantidad de esfuerzo que esto dependa depende en gran medida del desacoplamiento de las pruebas del código de producción. Cuanto más desacopladas estén las pruebas del código de producción, menor será el esfuerzo para hacer esto, cuanto más coherentes sean las pruebas con el código de producción, mayor será el esfuerzo.

La razón es simplemente esta: 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 también debería mantener las muestras de producción defectuosas. En casos raros, incluso eso puede valer la pena, y la burla y el uso inteligente de un sistema de control de versiones pueden reducir significativamente el esfuerzo, pero requiere desarrolladores muy por encima.

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

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

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

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

(1) Porque necesita documentar qué versión probó. Una versión etiquetada con un hash Git o un número de revisión 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 espera un fallo.

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

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

Podría, de vez en cuando, digamos una vez al año, hacer una "auditoría de control de calidad" encubierta. Tome una base de código "probada y en funcionamiento", y tantas nuevas características pequeñas de su lista de Todo como sea posible. Impleméntelos "un poco más descuidadamente" de lo que normalmente lo hace. Piense en los casos límite, escríbalos, pero no arregle su código para tenerlos en cuenta. Envíalo a QA.

Si encuentran más errores de caso de borde que no funcionan de lo que escribió, ciertamente no es su control de calidad el que necesita supervisión ... ;-)