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

267

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).
Krishnabhadra
fuente
59
"Una prueba debe pensar como un desarrollador" ... interesante. Pensé que era obvio que un probador no debería pensar como un desarrollador sino como un usuario.
Trilarion
12
¿Qué sucede si un error introducido intencionalmente cubre otro error que los evaluadores podrían haber encontrado si ese error intencional no se hubiera introducido? Por ejemplo, supongamos que un fragmento de código tiene un problema de poste de cerca y que el equipo de desarrollo no es consciente de este error. Un programador decide insertar un error de poste de cerca intencional en ese lugar. Ahora el código tiene un doble error de poste de cerca. Supongamos que los probadores detectan el error, pero no ven que se trata de un error de doble valla. ¡Felicidades! Los probadores encontraron un error introducido. El código original se restaurará para contener el error original de la cerca. ¡Uy!
David Hammen
20
Soy un QE Prefiero encontrar errores reales, gracias. Renunciaría a esta compañía como si estuviera en llamas. Nadie llega a (intencionalmente) perder mi tiempo.
ArjunShankar
77
"No hacemos esto en nuestra empresa, pero uno de mis amigos dice que su CTO le pidió a cada gerente de producto que agregue funciones adicionales al comienzo de cada ciclo de desarrollo de funciones ..."
Marco
3
Sospecho que agregar errores intencionales crea riesgos. ¿Qué pasa si un error intencional en realidad soluciona algo no deseado? El efecto secundario positivo no se informa, el código se elimina y un error real pasa el control de calidad. Por su naturaleza, estos "errores intencionales" de última hora no se considerarán, de lo contrario, los errores están desperdiciando demasiado tiempo del desarrollador.
Jodrell

Respuestas:

462

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.

James McLeod
fuente
17
El trabajo de QA es encontrar errores, no lo es; es para garantizar que el software tenga calidad de producción Esto requiere alguna aclaración. Aislar y corregir errores es un proceso importante en el envío de software de calidad de producción.
Krishnabhadra
21
En realidad, en muchas empresas, el trabajo de QA es encontrar errores, y si se agregaron nuevas características a un producto, y QA solo ejecuta un conjunto de pruebas que no muestra ningún error, personalmente no confiaré en ese conjunto de pruebas y supongo que es incompleto.
Doc Brown
8
Estoy de acuerdo, excepto por el último punto. Tener un tipo de enfoque contradictorio entre el control de calidad y el desarrollo (y los negocios) es en gran medida inevitable. Cada grupo tiene sus propios deseos y experiencia. Como empresa, estos deben equilibrarse para funcionar bien. En mi experiencia, "jugar bien" solo lleva a los grupos a no presionar por su agenda, lo que lleva al estancamiento o desequilibrio. Las mejores empresas que he visto han sido aquellas en las que el desarrollo, el control de calidad y el lado comercial presionan para satisfacer sus necesidades, pero actúan como un control sobre los demás, lo que lleva a comprometer el mejor equilibrio para la empresa.
Telastyn
42
Agregaría otro punto: un error intencional podría ocultar uno verdadero que habría aparecido si el error intencional no detuvo el proceso (al lanzar una excepción, por ejemplo) antes.
nkoniishvt
30
Si fuera un tipo de control de calidad y descubriera que estaba perdiendo el tiempo investigando y documentando errores de mierda introducidos a propósito, estaría encontrando un nuevo trabajo.
Kik
209

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.

Chispa - chispear
fuente
26
+1 Muy de acuerdo con los 4 puntos, especialmente el primero. El enfoque competitivo que aportan tantos desarrolladores nuevos a menudo refleja sus 15 años anteriores de escolarización, un entorno extremadamente competitivo, a diferencia del lugar de trabajo donde la cooperación sería un mejor enfoque.
Michael Durrant
1
Prefiero esta respuesta a la respuesta superior.
Pharap
1
"El control de calidad no solo está ahí para encontrar errores, sino también [...]" - Solo quiero decir que en muchos lugares, los términos prueba de software y garantía de calidad se usan indistintamente. Si, eso es malo. Donde solía trabajar, teníamos un empleado que usaba el estado, en cada reunión del departamento de control de calidad, lo que hacemos aquí no es garantía de calidad sino control de calidad. (Ella quiso decir esto como una crítica a nuestro departamento de control de calidad).
Mario
1. Es la escuela. Todos los días son días escolares. Si está trabajando en una disciplina de ingeniería pero no quiere aprender todos los días, debe salir de mi oficina. También es una entrevista. El rendimiento debe medirse todos los días para asegurarse de que el departamento obtenga una buena relación calidad-precio. 2. Si mi carrera me ha enseñado algo, es que QA tiene la capacidad mental de 14 años. Son niños y deben ser manejados como un rebaño de ovejas.
Gusdor
1. No es una escuela en el sentido de que las personas pueden colaborar y no competir entre sí por las calificaciones, no existe tal cosa como copiar su trabajo, ya que las tareas deben completarse solo una vez y no es una pena pedir ayuda a un colega. Y 2. Si su QA es tan malo, su problema está en RR. HH., Y esos son los que deberían salir de la oficina.
SparK
99

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.

Julia Hayward
fuente
32
Si pagan por error, entonces esto
BЈовић
12
"incentivado para encontrar los errores que sabes que están ahí" Excelente punto. Si una organización está haciendo esto, es probable que alguien esté respirando por el cuello de la gente de QA para asegurarse de encontrar los errores plantados, por lo que esa será su máxima prioridad. ¿Qué pasa si se juntan y se dan cuenta, dicen: "Hey, los errores plantados son casi siempre que no puede guardar un campo en una pantalla de edición con un montón de datos" (o lo que sea). Luego pasarán una cantidad excesiva de tiempo buscando ese tipo de error y aumentarán las posibilidades de que se pierdan otros tipos de errores.
Jay
Lo primero que me vino a la mente fue que Wally va a codificar a alguien más una minivan esta tarde
Dan Neely
10
> errores reales saliendo por la puerta. Solía ​​hacer grandes pruebas. Comienza con la tesis de que el código (no trivial) siempre tiene errores. QA son los héroes que los encuentran antes que el cliente. Los errores siempre están ahí. Si introduce errores artificiales, está perdiendo el tiempo que podría estar gastando en encontrar los errores reales; el tiempo para realizar las pruebas es limitado, está reduciendo la calidad al agregar trabajo innecesario.
RedSonja
58

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.

Arrozal
fuente
43
+1 para usted nunca prueba realmente su código de producción previsto en estos dos pases. Cómo puedo pensar en lanzar sin probar el código de producción está más allá de mí; Si está probando nuevamente sin los errores intencionales, entonces está repitiendo su esfuerzo y desperdiciando el esfuerzo inicial.
adamdc78
51

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",

Scott Whitlock
fuente
1
Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
Yannis
Hola a todos. La discusión se estaba haciendo demasiado larga para comentarios. Como puede ver en mi comentario anterior (automatizado), moví todos los comentarios a una sala de chat dedicada . Si desea continuar discutiendo la respuesta, hágalo en esa sala de chat y no aquí. Gracias.
Yannis
3
Así, el enfoque descrito podría usarse para probar el control de calidad ocasionalmente , no como un proceso permanente.
gerlos
30

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.

El más cuchara
fuente
28

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.

Roger Rowland
fuente
1
¡Me gusta la idea del poder del circuito de retroalimentación!
jxramos
23

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.

Schwern
fuente
Esta sería la única forma en que se podrían recopilar datos significativos. Pero la cantidad de tiempo y esfuerzo que se requeriría para determinar los casos de prueba adecuados para obtener resultados significativos arruinaría cualquier presupuesto y calendario. E incluso si le dieran el presupuesto y el cronograma, tendría que superar el obstáculo de asegurarse de tener personas calificadas para comprender las estadísticas y el software lo suficientemente bien como para poder identificar el subconjunto adecuado de pruebas. No creo que consigas todo eso en un solo proyecto. Entonces, en la vida real, lo mejor que puede hacer este método es obtener números erróneos, si no engañosos.
Dunk
1
La inyección SQL es una buena opción para hacerlo, ya que puede elegir n sentencias sql al azar para "romper"
Ian
1
Un gran problema es que los errores intencionales tenderán a ser muy diferentes de los problemas que obtendría de forma natural; es posible que simplemente esté entrenando a su QA para que piense como los programadores. Eso está prácticamente destruyendo todo el punto de control de calidad: tener un punto de vista más cercano al cliente que al código. Una gran parte del control de calidad es la comprobación de la cordura contra cosas que los desarrolladores piensan que son intuitivas (ya sea por ignorar la ignorancia de los usuarios o por la proximidad al código, el tiempo dedicado a la interfaz de usuario, etc.). Los errores intencionales no son una muestra bien distribuida.
Luaan
20

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.

Michael Durrant
fuente
77
Mi esposa hizo el control de calidad durante 8 años, y acaba de irse para el desarrollo, principalmente debido a problemas de confianza como este. Es insultante para el probador.
Bryan Boettcher
19

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.

Arrendajo
fuente
Ese punto sobre la especificación en "Dos" es una excelente analogía.
Kyralessa
14

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).

back2dos
fuente
55
Si dejaste esa primera oración, te habría hecho +1 porque todo lo demás es bueno :) Es simplemente una idea terrible, lo malo es un eufemismo. La manera más fácil de hacer que el control de calidad sea responsable es haciendo un seguimiento de la cantidad de errores que entran en el campo. Eso por sí solo logrará TODO lo que el método propuesto pretende ser sus beneficios.
Dunk
@Dunk: Hacer un seguimiento de ese número no mejorará automáticamente a tu equipo, al igual que mantener el puntaje en un deporte no te convierte en el mejor atleta que podrías ser. De hecho, los atletas entrenan , es decir, realizan tareas artificiales para aumentar su rendimiento de manera controlable, lo que no es muy diferente de lo que se propone aquí. A menos que tenga una idea de cómo hacer que las personas mejoren ese número, tiene poco valor.
back2dos
No pretendo que mejore nada. Solo afirmo que logrará todo lo que logrará el método de "insertar errores falsos" pero sin todos los costos y el tiempo perdido. Lo que hará es indicar si demasiados defectos están pasando por el control de calidad. Si se determina que es el caso, entonces el proceso o las personas deben ser reevaluados. El método de "error falso" no proporciona más información que esa, pero en realidad proporciona información menos útil. Por lo tanto, sus costos son más altos por menos ganancia utilizando el método de "error falso". Como dije, una idea terrible.
Dunk
@Dunk Entonces no leíste la pregunta correctamente. Sugiere que este método aumenta la moral y también la minuciosidad. Además, la cantidad de errores que pasan el control de calidad no mide de manera confiable la efectividad del equipo de control de calidad. Se ve igualmente afectado por la cantidad de errores que introducen los desarrolladores. Si comienzan a usar TDD y hay una disminución repentina de defectos en la versión, ¿qué dice eso sobre los probadores? Nada.
back2dos
@Dunk A diferencia de eso, el "error falso" en realidad le da más información, bajo el supuesto de que la dificultad de encontrarlos no fluctúa de manera errática (lo que se puede arreglar). Debido a que sabe cuántos defectos artificiales hay, puede saber exactamente qué porcentaje de ellos quedaron atrapados en el control de calidad. Por lo tanto, la información adicional que obtiene es la eficacia del control de calidad en la detección de defectos artificiales. Y ese número ciertamente se correlaciona más con su efectividad general que la que usted sugirió.
back2dos
9

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 .

James Mishra
fuente
7

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.

Tom Au
fuente
1
Creo que hay buenas partes en esto. Es mejor encontrar un error ANTES de que llegue a la naturaleza, y prefiero presionar mi control de calidad interno (¿eso es por lo que se les paga después de todo?) Que responder a ataques externos. Bug Hunting es una parte, y mientras este tipo de prueba se maneje adecuadamente, no veo por qué no puede ser una parte valiosa.
WernerCD
1
La copia del "original" puede no estar libre de errores y, por definición, también no se ha probado (porque el código se cambió para agregar errores).
Roger Rowland
1
En mi experiencia, los insectos no son animales aislados y no se sientan solos. El software es parte de un sistema y los errores, intencionales o no, afectan el sistema . A menos, por supuesto, que estemos hablando de piezas de software triviales.
Roger Rowland
18
No hay pruebas de que este método encuentre incluso 1 error adicional más allá de los errores insertados intencionalmente. No hay pruebas de que esto haga que el control de calidad trabaje más para encontrar errores. Pueden intentarlo menos duro. Además, dado que ha desperdiciado una ejecución completa del ciclo de prueba del procedimiento de prueba de aceptación mientras prueba el código roto intencionalmente (Nuestra prueba completa demora 3 semanas), ahora tiene que volver a probar con el código real que se implementará debido a que se rompió la versión no es la misma compilación, por lo que sus pruebas son prácticamente inútiles para la validación de la compilación "real".
Dunk
66
Supongo que Patton quería decir que debías tener un entrenamiento riguroso y ejercicios de campo durante el tiempo de paz. La analogía sería tener clases rigurosas en la escuela de TI o en la formación de postgrado. ¡Estoy bastante seguro de que Patton no quiso decir que los oficiales deberían recibir instrucciones de disparar a sus propias tropas desde atrás para mantener a las tropas alerta!
Jay
7

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.

JeffO
fuente
Definitivamente estoy de acuerdo con esto, lo que lleva a que se notifiquen problemas quisquillosos.
Adam Johns
@ AdamJohns: nunca se sabe con seguridad a menos que intente probarlo. Hay mejores formas, por lo que este sería casi un último recurso para mí.
JeffO
7

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.

yoniLavi
fuente
44
En lugar de hacer que los desarrolladores "inyecten" errores en el código, su tiempo sería mucho mejor para identificar cómo esos errores podrían haber entrado en el sistema y luego corregir el código para garantizar que esos errores no puedan suceder o sean manejados adecuadamente por El software. El objetivo de desarrollar un proyecto no es probar el sistema de control de calidad, es construir un sistema robusto y funcional que haga lo que sus usuarios quieren que haga.
Dunk
4

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.

Chris Pratt
fuente
2

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?"

Dominic Cronin
fuente
2

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 ...

Orquídea matemática
fuente
1

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 .

Christian Hujer
fuente
1

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.

DevSolar
fuente
1
Este es un argumento circular. Está diciendo que "la creación de errores en una compilación de prueba es incorrecta porque los desarrolladores no deberían hacer una compilación con código defectuoso conocido".
Dominic Cronin
@DominicCronin: nada circular al respecto. Cualquier cosa que se comprometa con el repositorio debería ser la mejor calidad posible. Hay una gran variedad de razones allí: evitar el cambio artificial de líneas de código es uno (wrt "svn blame" y funciones de repositorio similares). El peligro de "olvidarse" de eliminar el error nuevamente. El problema de que los probadores básicamente podían buscar lo que se había "sembrado" mirando el registro de cambios del repositorio. Muchas más razones, prácticamente sin beneficio para el contrapeso. Pero me estoy quedando sin espacio, y en cualquier caso la idea era proporcionar una , corta la razón.
DevSolar
@DominicCronin: O, para decirlo de otra manera, podría haber un caso para "sembrar" un error, pero la línea debe dibujarse bien antes de enviarlo al repositorio. Y, por otro lado, si bien tener un código "sembrado" para las pruebas puede tener una o dos cosas, solo debe probar el código comprometido . Las dos ideas, cada una de las cuales ya es controvertida por sí misma, simplemente no se conectan de ninguna manera sensata.
DevSolar
0

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 ... ;-)

Alejandro
fuente
2
Esto no parece ofrecer nada sustancial sobre los puntos hechos y explicados en las 16 respuestas anteriores
mosquito