Si ejecuta un proyecto con BDD con una cobertura del 100% de las historias de los usuarios con pruebas de aceptación automatizadas, ¿cuál sería el papel de un probador / 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 tonta.
Respuestas:
Tal vez soy demasiado anticuado, pero incluso las técnicas de desarrollo o proceso más modernas no pueden sustituir a otro par de 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 en la interfaz de usuario, definitivamente quiere 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%, no es una bala de plata .
100% de cobertura no es lo mismo que 100% probado.
Vería a una persona de QA 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 IU, pruebas de destrucción y pruebas de carga / estrés.
Pero nunca he elaborado un proyecto ATDD.
El trabajo de QA es romper la aplicación, el trabajo de los desarrolladores es no romperla. Por lo tanto, escriben sus pruebas desde una perspectiva diferente. Por ejemplo, los desarrolladores 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 detectarán cuándo su interpretación es diferente de lo que el desarrollador pensó que significaba y luego se reunirán con las partes interesadas del proyecto para determinar cuál es la interpretación correcta. Las pruebas escritas por 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 extremos.
En un empleador anterior, el papel de QA era no probar el producto, sino garantizar que los desarrolladores esencialmente hicieran lo que dijeron que iban a hacer con respecto a las pruebas de aceptación previamente definidas que fueron definidas por QA.
El propietario del producto, por otro lado, no tuvo absolutamente nada que ver con las pruebas. Tratar con las pruebas en cualquier nivel en mi humilde opinión no es el papel del propietario del producto.
En algún momento debe tener confianza en sus empleados; los controles y equilibrios 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 la colaboración con dev y QA formalizándose con la redacción de las pruebas de aceptación de manera conjunta. El control de calidad debería aportar un aspecto diferente a la mesa, 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, debe contratar QA para comprender cuál es el estado actual del producto, los riesgos, etc. y enfocarse en el producto de manera holística; no los matices específicos que componen el producto.
Desde mi experiencia: estábamos usando la prueba de la 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 pruebas - escribir 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 está aplicando el enfoque de 3 Amigos donde las partes interesadas 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 producirá el mismo resultado.
Los desarrolladores no reescriben los requisitos y 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 escritas que los desarrolladores ejecutan como pruebas de aceptación. ¡Es hora de que los desarrolladores usen algo del sombrero de control de calidad!