Si ejecuta un proyecto utilizando BDD con una cobertura del 100% de historias de usuarios con pruebas de aceptación automatizadas, ¿cuál sería el rol de un evaluador / persona de control de calidad?
Supongo que estoy imaginando que los desarrolladores escribirían las pruebas de aceptación junto con el propietario del producto; avíseme si eso parece una suposición absurda.
Tal vez sea demasiado anticuado, pero incluso las técnicas más modernas de desarrollo o proceso no pueden sustituir a otros ojos, ojos nuevos, antes de lanzar un producto a su cliente.
Incluso si su producto es simplemente una API para otro desarrollador, puede usar el control de calidad para pensar como el usuario de la API, proporcionando escenarios de prueba / uso que usted o su cliente no pensaron de antemano.
Si su producto se basa principalmente en la interfaz de usuario, definitivamente desea que otra persona (que no sea usted o alguien de su equipo) busque el resultado final antes de enviarlo al cliente.
Al igual que cualquier otra palabra de moda en nuestra industria, BDD, incluso con una cobertura del 100%, es sin viñeta de plata .
100% de cobertura no es lo mismo que 100% probado.
Vería a una persona de control de calidad en un proyecto ATDD como alguien que ayudaría a escribir las pruebas y realizar los otros tipos de pruebas que aún existen. Es decir. Pruebas de interfaz de usuario, pruebas de destrucción y pruebas de carga / estrés.
Pero nunca he elaborado un proyecto ATDD.
El trabajo de control de calidad es romper la aplicación, el trabajo de los desarrolladores es no romperla. Por eso escriben sus tests desde una perspectiva diferente. Por ejemplo, los devs escriben pruebas para ver si ocurre el comportamiento esperado, QA escribe pruebas para ver qué sucede cuando los usuarios hacen algo que el desarrollador nunca consideraría que haría el usuario. Además, los desarrolladores a menudo malinterpretan los requisitos y las pruebas de control de calidad se detectan cuando su interpretación es diferente de lo que el desarrollador pensó que significaba y luego se reúnen con los interesados del proyecto para determinar cuál es la interpretación correcta. Las pruebas escritas por los desarrolladores que escribieron el código a menudo tienen grandes puntos ciegos porque el desarrollador tenía un gran punto ciego. Por ejemplo, podría probar lo que sucede el 97% del tiempo pero no los casos de borde.
En un empleador anterior, el rol de control de calidad era no probar el producto, sino garantizar que los desarrolladores esencialmente hicieron lo que dijeron que harían con respecto a las pruebas de aceptación definidas previamente que fueron definidas por control de calidad.
El propietario del producto, por otro lado, no tuvo absolutamente nada que ver con las pruebas. La gestión de las pruebas a cualquier nivel IMHO no es la función del propietario del producto.
En algún momento debe tener confianza en sus empleados; los controles y balances son buenos, pero no debería tener que forzar una solución dentro del ciclo de desarrollo que en realidad es solo abordar un pequeño subconjunto de la ética de trabajo de los empleados.
En un mundo perfecto, veo que la colaboración con dev y QA se formaliza con la redacción de las pruebas de aceptación de manera conjunta. El control de calidad debe aportar un aspecto diferente a la tabla al igual que el equipo de desarrollo. El control de calidad debe tener su mano en el pastel en la infancia del producto y permanecer comprometido durante todo el ciclo. El propietario del producto, por otro lado, debería entonces comprometerse con el control de calidad para comprender el estado actual del producto, los riesgos, etc. y centrarse en el producto de manera integral. no los matices específicos que componen el producto.
Desde mi experiencia: Estábamos usando la prueba de unidad para cubrir más del 90% del código. También hubo pruebas de integración y compilaciones por hora. jBehave pruebas para BDD.
rol de control de calidad: - Adoptar historias de usuario para la prueba. - escribiendo código detrás de los pasos - pruebas de exploración utilizando el complemento RestClient para IDEA (por lo tanto, encontramos algunos errores importantes)
Parte de BDD es aplicar el enfoque de 3 Amigos donde los interesados colaboran para producir los criterios de aceptación. QA / Dev puede escribir el código de paso para hacer que los escenarios se ejecuten como pruebas de aceptación. ¿Dónde está el valor de QA para ejecutar manualmente las mismas pruebas de aceptación que una herramienta BDD ejecutará automáticamente? El valor agregado de QA es validar esas pruebas de aceptación y realizar pruebas exploratorias manuales fuera de las pruebas de aceptación programadas. La duplicación generalmente produce el mismo resultado.
Los desarrolladores no reescriben los requisitos y las especificaciones, el control de calidad no reescribe el código de la aplicación ... es posible que el control de calidad no tenga que realizar las mismas pruebas con script que los desarrolladores ejecutan como pruebas de aceptación. ¡Es hora de que los Devs usen parte del sombrero de control de calidad!
Lea otras preguntas en las etiquetas bdd testing team qa acceptance-testing