No los uso, y no creo que tengan un lugar en el desarrollo de software.
- Alientan / fuerzan otra herramienta en un grupo que necesita estar colaborando con las personas que escriben los requisitos y crean características. Estas herramientas molestan a esas personas (en el mejor de los casos), con muy poco valor agregado.
- Agrega una capa de informes y trabajo extra manual que no está probando. Todos deben estar lo más cerca posible al 100% posible. “Oye, ¿fuiste a la herramienta de administración de casos de prueba y actualizaste los números de aprobación / falla? No está probando. Obliga a un contexto no natural a cambiar a las personas que deberían usar sus habilidades de prueba por el bien del producto.
- El hecho de que los informes que surjan de estos hagan felices a los gerentes (y a los jefes del gerente felices) no significa que tengan valor. Son una manta de seguridad que no debe hacer que nadie se sienta seguro.
- El enfoque es * generalmente * en lo incorrecto. Un gerente quiere ver los números de pasa / falla. “Pasó el 8/10, lo cual es normal”. Él / ella sonríe porque el 80% es lo suficientemente bueno, te palmea la espalda. Te sientes bien porque crees que hiciste tu trabajo. Pero, ¿por qué no se empareja con un desarrollador para comunicar que las pruebas 2/10 fallan continuamente? ¿Cómo puedes ayudar a solucionar esto?