En caso de que los programadores probadores de ayuda en el diseño pruebas?
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
¿Cuánto se debe probadores programadores de ayuda en las pruebas de diseño?
No creo que deberían ayudar en absoluto. Mi preocupación es que si ayudan a los probadores en las pruebas para el diseño de su propio código, que van a 'infectar' los probadores con sus propios prejuicios y puntos ciegos sobre ese código.
Siento que los requisitos deben ser suficientes para dar la información necesaria para que los evaluadores para crear sus pruebas. Si hay alguna parte de la aplicación que los programadores encuentran preocupante, entonces yo creo que es su deber de aplicar las pruebas de unidad a prueba de que parte o incluso ejecutar sus propias pruebas del sistema informal a prueba esa parte.
No todo el mundo que conozco está de acuerdo con esto, sin embargo (y entiendo algunos de sus puntos, hasta cierto punto). ¿Qué es lo que otros piensan acerca de esto? Está presente discutido en la literatura en cualquier lugar?
Solución
Estoy de acuerdo. Los programadores pueden ayudar a los probadores para entender las especificaciones funcionales, para encontrar recursos para la investigación, pero no deben contaminar la mente de los probadores con sus propias ideas sobre cómo abordar la prueba.
Otros consejos
Creo que hay espacio para los desarrolladores y probadores de coexistir pacíficamente en el ámbito de control de calidad. :)
Más específicamente, creo que los desarrolladores deben ser responsables para el primer nivel de la prueba - pruebas unitarias y pruebas de integración básicas para asegurarse de que sus cosas funciona en la mayoría de los casos antes de que se entreguen fuera de los probadores.
Todo depende de los probadores para crear pruebas de aceptación en base a los requisitos que son completamente agnóstico de los detalles de implementación (esto se conoce normalmente como 'pruebas de caja negro'). Si hay una discrepancia en la forma probadores y desarrolladores a entender los requisitos, que es un problema que debe ser abordado ya sea por el director del proyecto (si lo hay) o por asegurarse de que todos estén en la misma vuelta de página en la fase de diseño de la función.
Creo que las dos pruebas y el desarrollo son colaboración esfuerzos, así que por supuesto (OMI), los desarrolladores deberían dar ideas a prueba los probadores. No creo que ellos o corrupciones probadores infecta a todos. El probador, por supuesto, debe mejorar esas pruebas con muchas otras pruebas de enfoques.
También soy un gran fan de los probadores de ayudar a los desarrolladores - He lluvia de ideas ideas de diseño con los desarrolladores y vinculado con ellos para arreglar errores (y señaló los errores y sugirieron correcciones) muchas veces en mi carrera, y no hacer creo que he mancillado un desarrollador con piojos probador.
Si no lo ve como un esfuerzo de colaboración, que sólo tendrá código "arrojado por encima del muro" de dev a prueba ... y que va a terminar con una menor calidad. Esa es la verdad en mi mundo, pero (por supuesto), tu caso es distinto.
La forma en que veo es que no es el trabajo de control de calidad para probar mi código. El trabajo del probador es asegurarse de que el código cumple con todos los requisitos para esa tarea.
Cuando paso algo para control de calidad, me aseguro de que conocen la tarea que estaba haciendo, no los detalles de mi código. Nunca pasa nada de control de calidad que tiene errores 'de hueso jefe' en el mismo. Que los residuos mi tiempo, su tiempo ... y la hora más o menos de todos.
En mi último trabajo, tuvimos QA involucrado desde el principio. Que estaban sentados en los requisitos de la recopilación de las sesiones, las reuniones del proyecto, y las reuniones de diseño también. Ellos escucharon e hicieron preguntas y mientras los desarrolladores estaban escribiendo código, que estaban escribiendo sus planes de prueba. Que funcionaba de maravilla y cogimos un montón de cuestiones que probablemente se habría deslizado a través.
Creo que estás muy equivocada aquí. He sido un probador y un desarrollador, y han beneficiado en gran medida como un probador de orientación por los desarrolladores en las áreas que se consideran de alto riesgo o frágiles; como desarrollador, quiero probadores para encontrar los problemas que no se han investigado profundamente.
No hubo ninguna "contaminación" a menos que su código es aguas residuales sin tratar, y que sería por una razón completamente diferente.
Requisitos hacen un trabajo terrible de comunicar las cuestiones técnicas que un profesional de control de calidad le importaría, porque se elaboran a lo sumo lo que los analistas de negocios han logrado la captura. Los buenos desarrolladores serán conscientes de que su código se optimiza todo el "camino feliz", y va a querer saber lo que han dejado desconsiderada. Ellos tienen al menos una intuición de lo que podía salir mal, y qué áreas les gustaría control de calidad para la sonda. También saben lo que el panorama general es de riesgo en torno a una característica particular en función de su diseño.
Como probador orientación ausente del equipo de desarrollo, a veces he ido fuera en un enfoque equivocada que genera buenos informes de errores, pero no ejerció por completo las rutas de código de alto riesgo y problemas más grandes, que podrían haberse evitado mediante una mejor colaboración con el equipo de desarrollo, enviados a los clientes.
Mientras que un probador sin duda no debe limitarse a probar justo lo que el desarrollador dice que es importante, que no será dañada por el aprendizaje de lo que los desarrolladores propias preocupaciones sobre el código son. A veces, pueden afinar su enfoque basado en el conocimiento de la aplicación. Sólo si un probador está particularmente miope-van a tener en cuenta la opinión de los desarrolladores acerca de cuáles son los riesgos como la última palabra; que no corta por completo las cosas que los identifica como desarrollador de bajo riesgo, pero que va a invertir más esfuerzo en las cosas que podrían tener un mayor impacto sobre los usuarios.
Es probable que las áreas que tienen un ámbito prueba combinatoria grande que los recolectores requisitos o los desarrolladores de un sistema El equipo de control de calidad, pero pueden no ser conscientes de los componentes del sistema que tienen una más sutil tipo de fragilidad que se beneficia de la conciencia del diseño o la implementación del sistema.
En mi experiencia, la colaboración entre QA y Desarrollo produce productos de mejor calidad. Nunca recomendaría hacer sólo una caja de transferencia negro.
Como probador, no tengo objeción alguna a los programadores que sugieren casos de prueba (aunque eso no quiere decir que me quedo sólo a aquellos casos de prueba), o describir los detalles de implementación. A veces puede ser muy útil tener a alguien decir "Creo que este bit podría ser arriesgado, realmente me gustaría que si usted probó este bit bastante a fondo". Conocer algunos de los detalles de implementación me ayuda a aplicar años de experiencia para elegir las pruebas que pienso más propensos a fallar. A veces, sólo una breve mención significa unas cuantas pruebas repente zoom justo en mi lista de prioridades.
¿Me vea contaminado? Estoy un poco cosquillas por la idea de programadores caballerosamente que se esfuerzan por preservar la pureza de mi probador, pero en realidad - no, esto es un mito. Más información generalmente desencadena aún más preguntas para mí, no menos. Creo que es una cosa de pensar - no encuentro errores porque soy ignorante, encuentro problemas porque soy un tipo escéptico, desconfiado que sólo es demasiado terco darn a tomar cualquier cosa en su totalidad en la confianza. En todos los sistemas que he probado, me he dado cuenta que me parece más problemas, y más queridos "interesantes", más profundamente llego a entenderlo.
I like to review the test plans and suggest additional test cases that QA might not have thought of. I'm not sure how that would "infect the testers with my own prejudices".
I found myself in this weird position that I need to implement and write test cases in Selenium afterward since we're short on QA staff. I believe test-driven development would be extremely helpful but it's not adapted in my shop yet.
One thing I find writing tests helpful is that I find bugs when I write tests. I think in different perspective to help me write more robust code. But it's true that the test coverage could be limited. In this case, QAs can always let us know what they would like to be covered. Or, we can passively add more tests when we see errors.
I'm doing QA, and unlike most domains knowing how to use our code is far more difficult than learning any programming lanquage. So we count on developers to give us test cases for their brand new whizzbang features, because we wouldn't know how to. In any case the QA problems are more to catch regressions and things that get broken than original testing of new features. In any case when the result is a complex computation, its hard to know what is a correct answer and what is a wrong answer, or even if an abnormal termination is a good or bad thing.
In any case, a developer, if he's honest probably knows something of his babies vulnerabilities. He probably knows at what parameter values, he has to select different algorithms, or domains in a table lookup or whatever. Knowing that, if he is sincere about rigorous testing, he should be able to generate a reasonable sized suite of tests that covers a lot of the code.
