Si tenemos TDD y BDD, ¿para qué necesitamos un control de calidad? [duplicar]

7

Si tenemos TDD y BDD , ¿por qué necesitamos QA para? ¿No es el trabajo del desarrollador escribir errores o fallar las pruebas? Si esto es cierto, ¿cómo encaja un control de calidad? Gracias.

    
pregunta gnat 19.09.2014 - 19:47

5 respuestas

18

Los desarrolladores son muy, muy buenos en la abstracción. Si nos da la mitad de un problema, encontraremos la solución completa. De hecho, somos tan buenos en esto que ni siquiera nos daremos cuenta de que solo tenemos la mitad del problema. Somos gente de "espacio de solución". Nuestro trabajo es resolver problemas.

Los probadores, por otro lado, son personas del "espacio de problemas". Ellos son los que preguntan: "¿Qué pasa con X? ¿O con Y? ¿Has pensado en Z?" Saben cómo romper nuestro código incluso antes de que lo hayamos escrito. Si somos realmente amables con ellos, nos lo dirán. Su trabajo es entender el problema al revés.

Un analista o una PYME puede ser bueno para determinar qué problemas son los más importantes de resolver, pero una vez que han tomado esa decisión, los evaluadores son tan buenos como lo son al comprender la naturaleza del problema elegido. Los desarrolladores tienden a no ser buenos en esto debido a nuestras cabezas de "espacio de solución"; nos cegamos a las cosas que no sabemos.

En un entorno en el que estás haciendo BDD o TDD, los evaluadores son invaluables para ayudarte a ti y al negocio, a detectar las pruebas o los escenarios que te perdiste. También son excelentes para hacer pruebas exploratorias, por lo que encuentran las cosas que las pruebas automatizadas no pueden (por ejemplo, uno de mis evaluadores favoritos descubrió que había puesto una llamada de SQL en el lugar equivocado y que un comportamiento en particular estaba haciendo 10 llamadas a la base de datos donde solo se necesita hacer 1).

Tiendo a referirme a "tester" en estos días en lugar de "QA", ya que asegurar la calidad es, como dijo gurun, más que solo una persona y un poco de proceso.

    
respondido por el Lunivore 21.09.2014 - 21:57
7

TDD es una herramienta de diseño utilizada por los desarrolladores, se trata más de diseño que de pruebas y verificaciones.

BDD es una herramienta de comunicación para cerrar la brecha entre desarrolladores, control de calidad, propietarios de productos o analistas de negocios. BDD se asegura de que compartamos la misma visión de lo que se necesita construir utilizando ejemplos concretos en lugar de confiar en una especificación abstracta.

El control de calidad es un rol con la responsabilidad de pruebas de verificación en cuanto a características, seguridad, rendimiento, cumplimiento, etc. El control de calidad también puede ser responsable de proporcionar herramientas de automatización de pruebas. .

Como pueden ver, son tres cosas ortogonales (en un espacio tridimensional, por supuesto).

    
respondido por el foobarcode 20.09.2014 - 05:27
2

Es ciertamente discutible que usted no necesita "QA", aunque eso depende de lo que quiere decir con "QA". ¿Necesita un equipo o departamento de control de calidad separado? Probablemente no. ¿Necesita profesionales capacitados en control de calidad? Probablemente sea así.

La prueba es una habilidad, y normalmente no es una habilidad que la mayoría de los desarrolladores tienen. Cada equipo debe tener entrenadores profesionales y entrenados. Su trabajo debe ser asegurarse de que el software esté bien probado, tanto trabajando con los desarrolladores para escribir buenas pruebas durante el desarrollo, como para realizar sus propias pruebas, como pruebas exploratorias de extremo a extremo.

Como analogía, piense en un inspector de construcción. Por ejemplo, si un carpintero comprueba que el techo que construyeron no tiene fugas, ¿por qué tener un inspector de construcción? ¿Acabas de tomar la palabra del carpintero? Aún necesita un inspector de construcción porque conoce los errores comunes que se cometen y cómo detectarlos.

Entonces, incluso si tiene un equipo de desarrollo que realiza conscientemente TDD, ATDD, BDD o una de sus variantes, aún necesita probadores capacitados para asegurarse de que tiene un software bien probado.

    
respondido por el Bryan Oakley 19.09.2014 - 19:57
1

los scripts de prueba automatizados ayudan con la lógica y hacen clic en la aplicación para garantizar que todo se conecte bien.

Lo que no tiene en cuenta es:

¿se ha verificado el script automatizado para todas las funciones creadas? ¿comprueba la lógica correctamente?

Por último: El diseño del diseño no se comprueba aquí. Los evaluadores con agudos ojos para los detalles son muy útiles para captar muchas cosas pequeñas en la experiencia de la interfaz de usuario entre diferentes tamaños de pantalla, plataformas y dispositivos. Además, más globos oculares en el software que comprueba las cosas tienden a mejorar el flujo lógico para una mejor experiencia de UI con menos confusión.

    
respondido por el user2174484 19.09.2014 - 19:55
1

Usted escribió "Si esto es cierto, ¿cómo encaja un control de calidad?" lo que implica que estás hablando de una persona responsable de control de calidad. Volveré a eso al final de la respuesta.

Control de calidad y control de calidad son dos conceptos muy distintos. Creo que cuando nosotros, como desarrolladores, hablamos de control de calidad, nos referimos con mayor frecuencia a las personas que crean las pruebas, las ejecutan o ambas cosas. Para mí, la garantía de calidad es la planificación sistemática y la documentación de las actividades relacionadas con la calidad. Lo más a menudo documentado en un sistema de calidad general. Hacemos eso para proporcionar algún tipo de "seguridad" de que nos importa (en un lenguaje sencillo). El control de calidad, para simplificarlo, son actividades relacionadas con la verificación de que estamos siguiendo el plan.

Entonces, cuando hace esta pregunta, necesita colocar TDD, BDD (o cualquier otra práctica, metodología, técnica, etc.) en la categoría correcta. También tienes que descubrir qué quieres decir con control de calidad.

Blunt; El hecho de que alguien esté haciendo TDD no significa que habrá calidad. Tampoco significa que incluso si alguien es bueno en hacer TDD, será suficiente cobertura. Además, el sistema de calidad incluiría criterios sobre la cantidad de pruebas que sería suficiente, y a menudo puede ser tan simple como "probar lo que se necesita probar". Pero en un sistema de calidad real, esa definición no podría sostenerse por sí misma, por supuesto. Debe poder juzgar esto desde una posición imparcial como sea humanamente posible.

Creo que a menudo hay una idea errónea de que QA / QC necesita requisitos de documentos, pruebas, etc. A menudo tengo que argumentar (con nuestro QA) que quality no se crea por el proceso En sí mismo . La calidad debe existir en el desarrollo, y la función del proceso es recopilar pruebas suficientes para demostrar que usted tiene calidad. Eso significa que el control de calidad desde la perspectiva de "tener un plan" es en realidad más importante para mí que el control de calidad. Y ahí es donde TDD y BDD desempeñan un papel como actividades y prácticas que practicamos para asegurar resultados de calidad de nuestro trabajo.

Un QA mientras lo escribes, como si estuvieras pensando en una persona específica, probablemente significa lo que usualmente llamamos QAE (ingeniería). Eso es básicamente el arte y el negocio de crear material para verificación y validar el resultado de la codificación. Y es verdaderamente un arte. Una persona / departamento que realiza QAE generalmente hace mucho más que probar el sistema individualmente, ya que las actividades de verificación y validación por lo general van más allá del BDD / TDD básico. Pero desde una "perspectiva de programadores" pura, tiendo a considerar esto como una responsabilidad. Y luego depende en gran medida de la estructura de la organización, el tamaño, el negocio, etc., si esa responsabilidad está relacionada con un rol (o varios).

Argumentaría firmemente que, independientemente de cómo y qué hagas, siempre necesitas y tienes un control de calidad. Siempre tienes QC. Siempre tienes QAE. Es solo que en equipos pequeños esto podría no ser un recurso, rol u organización explícita.

Entonces, ¿cuál es el papel de TDD en todo esto? Bueno, para mí no podría tener ningún rol, o significar todo. TDD para mí es un enfoque para escribir código, no para escribir pruebas. La gente parece discutir sobre cosas como "el estilo de Londres es mejor que el de Chicago o incluso el de Piteå". Yo diría que el estilo Piteå siempre gana, ya que es mi estilo . Y el estilo Piteå significa que la mayoría de las veces, después de escribir un estilo TDD extremo, termino con todo, desde funcional, integración, unidad, caja negra, caja blanca. Lo único que puedo asegurar es que, a partir del estilo TDD Piteå, siempre termino con mucho más simple, más al punto, más cubierto, mejor construcción ... código . El estilo de Piteå también exige que está perfectamente bien no producir ningún código en absoluto, si la calidad así lo exige . De vez en cuando, el estilo de Piteå exige una cerveza o varias, pero ese es un tipo diferente de garantía de calidad. En el sistema de calidad de Piteå, TDD es la base sobre la que construyo mi garantía de que lo que produzco será de la calidad suficiente y poder conservarlo más tarde. Y mi servidor de CI es incansable y controla continuamente que no cometa errores.

Pero en última instancia, en lo que respecta a la calidad real, solo los usuarios de mi código pueden ser testigos. Solo puedo asegurarles que hago calidad de la mejor manera posible. Calidad primero, siempre, luego TDD.

[Piteå es mi ciudad natal]

    
respondido por el gurun 20.09.2014 - 21:33

Lea otras preguntas en las etiquetas