¿Deberían los programadores ayudar a los evaluadores a diseñar las pruebas?

¿Cuánto deberían ayudar los programadores a los probadores a diseñar pruebas?

No creo que deberían ayudar en absoluto. Mi preocupación es que si ayudan a los evaluadores a diseñar pruebas para su propio código, 'infectarán' a los evaluadores con sus propios prejuicios y puntos ciegos sobre ese código.

Creo que los requisitos deberían ser suficientes para proporcionar la información necesaria para que los evaluadores creen sus pruebas. Si hay una parte de la implementación que los programadores consideran preocupante, entonces creo que es su deber implementar pruebas unitarias para probar esa parte o incluso ejecutar sus propias pruebas informales del sistema para probar esa parte.

Sin embargo, no todos los que conozco están de acuerdo con esto (y entiendo algunos de sus puntos hasta cierto punto). ¿Qué piensan los demás sobre esto? ¿Se discute esto en la literatura en alguna parte?

Estoy de acuerdo. Los programadores pueden ayudar a los evaluadores a comprender las especificaciones funcionales, a encontrar recursos para la investigación, pero no deben contaminar las mentes de los evaluadores con sus propias ideas sobre cómo abordar las pruebas.

Creo que hay espacio para que los desarrolladores y evaluadores coexistan pacíficamente en el ámbito del control de calidad. :)

Más específicamente, creo que los desarrolladores deberían ser responsables del primer nivel de pruebas: pruebas unitarias y pruebas de integración básicas para asegurarse de que sus cosas funcionen en la mayoría de los casos antes de entregarlos a los probadores.

Depende de los evaluadores crear pruebas de aceptación basadas en los requisitos que son completamente independientes de los detalles de implementación (esto generalmente se conoce como 'prueba de caja negra'). Si existe una discrepancia en la forma en que los probadores y los desarrolladores entienden los requisitos, es un problema que debe abordar el gerente del proyecto (si corresponde) o asegurarse de que todos estén en la misma página en la fase de diseño de la función.

Creo que tanto las pruebas como el desarrollo son esfuerzos de colaboración , por lo que, por supuesto (IMO), los desarrolladores deben dar ideas de prueba a los probadores. No creo que los infecte o contamine a los probadores en absoluto. El probador, por supuesto, debe mejorar esas pruebas con muchos otros enfoques de prueba.

También soy un gran admirador de los probadores que ayudan a los desarrolladores: hice una lluvia de ideas de diseño con los desarrolladores y los emparejé para corregir errores (y señalé los errores y las soluciones sugeridas) muchas veces en mi carrera, y no creo que ' alguna vez he contaminado a un desarrollador con probadores cooties.

Si no lo ve como un esfuerzo de colaboración, solo tendrá un código "arrojado por la pared" del desarrollador para probar ... y terminará con una calidad inferior. Esa es la verdad en mi mundo, pero (por supuesto), mmm.

La forma en que lo veo es que no es el trabajo de QA probar mi código. El trabajo del probador es asegurarse de que mi código cumpla con todos los requisitos para esa tarea.

Cuando paso algo al control de calidad, me aseguro de que sepan la tarea que estaba haciendo, no los detalles de mi código. Nunca paso nada al control de calidad que tenga errores de 'cabeza de hueso'. Eso desperdicia mi tiempo, su tiempo ... y casi el tiempo de todos.

En mi último trabajo, tuvimos un control de calidad desde el principio. Eso se sentó en las sesiones de reunión de requisitos, las reuniones del proyecto y las reuniones de diseño también. Escucharon y formularon preguntas y mientras los desarrolladores escribían código, escribían sus planes de prueba. Funcionó muy bien y descubrimos muchos problemas que probablemente se habrían deslizado.

Creo que estás bastante equivocado aquí. He sido probador y desarrollador, y me he beneficiado enormemente como probador de la orientación de los desarrolladores en áreas que consideraban de alto riesgo o frágiles; Como desarrollador, quiero que los evaluadores encuentren los problemas que no he investigado profundamente.

No hubo "contaminación" a menos que su código sea de aguas residuales, y eso sería por una razón completamente diferente.

Los requisitos hacen un trabajo terrible al comunicar los problemas técnicos que le interesaría a un profesional de control de calidad, porque elaboran, en el mejor de los casos, solo lo que los analistas de negocios han logrado capturar. Los buenos desarrolladores sabrán que su código está optimizado en torno al "camino feliz", y querrán saber lo que han dejado sin considerar. Al menos tendrán una intuición de lo que podría salir mal y qué áreas les gustaría que investigara QA. También saben cuál es el panorama general del riesgo en torno a una característica particular en función de su diseño.

Como probador sin la guía del equipo de desarrollo, a veces he seguido un enfoque equivocado que generó buenos informes de errores, pero no ejercité por completo las rutas de código de alto riesgo y los problemas más grandes, que podrían haberse evitado mediante una mejor colaboración con el equipo de desarrollo, enviado a los clientes.

Si bien un probador ciertamente no debería limitarse a probar solo lo que el desarrollador dice que es importante, no se dañará al aprender cuáles son las preocupaciones de los desarrolladores sobre el código. A veces, pueden ajustar su enfoque en función de su conocimiento de la implementación. Solo si un probador es particularmente miope considerarán la opinión del desarrollador sobre cuáles son los riesgos como la última palabra; no cerrarán por completo las cosas que el desarrollador identifica como de bajo riesgo, pero invertirán más esfuerzo en cosas que podrían tener un mayor impacto en el cliente.

Es probable que el equipo de control de calidad vea áreas que tienen un gran alcance de prueba combinatoria que los recolectores de requisitos o desarrolladores de un sistema, pero es posible que no conozcan los componentes del sistema que tienen un tipo de fragilidad más sutil que se beneficia de la conciencia del diseño o implementación del sistema.

En mi experiencia, la colaboración entre QA y Desarrollo produce productos de mejor calidad. Nunca recomendaría hacer solo una transferencia de caja negra.

Como probador, no tengo ninguna objeción para que los programadores sugieran casos de prueba (aunque eso no significa que me limitaré a esos casos de prueba) o que describan los detalles de implementación. A veces puede ser realmente útil hacer que alguien diga "Creo que esta parte podría ser arriesgada, realmente me gustaría si la probaras bastante". Conocer algunos de los detalles de implementación me ayuda a aplicar años de experiencia para elegir las pruebas que creo que tienen más probabilidades de fallar. A veces, solo una breve mención significa que algunas pruebas de repente aumentan mi lista de prioridades.

¿Me contamina? Me hace cosquillas la idea de que los programadores se esfuercen caballerosamente por preservar la pureza de mi probador, pero en realidad, no, esto es un mito. Más información generalmente me genera aún más preguntas, no menos. Supongo que es una cuestión de mentalidad: no encuentro errores porque soy ignorante, encuentro problemas porque soy un tipo escéptico y desconfiado que es demasiado terco para confiar completamente en algo. En cada sistema que probé, descubrí que encuentro más problemas y más "interesantes", cuanto más lo entiendo.

Me gusta revisar los planes de prueba y sugerir casos de prueba adicionales en los que QA podría no haber pensado. No estoy seguro de cómo eso "infectaría a los evaluadores con mis propios prejuicios".

Me encontré en esta posición extraña que necesito implementar y escribir casos de prueba en Selenium después ya que nos falta personal de control de calidad. Creo que el desarrollo basado en pruebas sería extremadamente útil, pero aún no está adaptado en mi tienda.

Una cosa que encuentro útil al escribir pruebas es que encuentro errores cuando escribo pruebas. Pienso en una perspectiva diferente para ayudarme a escribir código más robusto. Pero es cierto que la cobertura de la prueba podría ser limitada. En este caso, los QA siempre pueden hacernos saber qué les gustaría que se cubrieran. O bien, podemos agregar pasivamente más pruebas cuando vemos errores.

Estoy haciendo el control de calidad y, a diferencia de la mayoría de los dominios, saber cómo usar nuestro código es mucho más difícil que aprender un lenguaje de programación. Así que contamos con los desarrolladores para que nos den casos de prueba para sus nuevas funciones de whizzbang, porque no sabríamos cómo hacerlo. En cualquier caso, los problemas de control de calidad son más para atrapar regresiones y cosas que se rompen que las pruebas originales de nuevas características. En cualquier caso, cuando el resultado es un cálculo complejo, es difícil saber cuál es la respuesta correcta y cuál es la respuesta incorrecta, o incluso si una terminación anormal es algo bueno o malo.

En cualquier caso, un desarrollador, si es honesto, probablemente sepa algo de las vulnerabilidades de sus bebés. Probablemente sepa con qué valores de parámetros, tiene que seleccionar diferentes algoritmos o dominios en una búsqueda de tabla o lo que sea. Sabiendo que, si es sincero acerca de las pruebas rigurosas, debería ser capaz de generar un conjunto de pruebas de tamaño razonable que cubra gran parte del código.