Asumo, usted ya debe haber oído esto en algún momento de su vida. Esto es sólo una de las frases repetidas incompletas hasta el punto de que muchas personas creen que es un hecho. Bueno, permítanme ser claro entonces que es precisamente la falta de completitud lo que hace que a la frase incorrecta. Los desarrolladores no odian probar.
Los desarrolladores odian probar manualmente.
Esta es una gran diferencia y siempre me molesta cuando la gente inteligente deja de aplicar su tiempo en la automatización para realizar, una y otra vez, pruebas manuales. Si usted todavía pierde tiempo realizando pruebas manuales, sepa que están llenos de problemas: llevan más tiempo para se reproducidas, son propensas a errores, no aprovechan lo que las personas tiene mejor, no pueden ser ampliados para hacer frente a otros aspectos del software (tales como performace, por ejemplo) y no indican exactamente donde la funcionalidad está rota.
Nosotros - como desarrolladores - trabajamos para automatizar lo más posible nuestro día a día e incluso el día a día los clientes. Las computadoras son excelentes para repetir tareas, sabemos que, entonces es realmente incómodo realizar pruebas manuales, porque la sensación es que algo está mal. Como nadie persona con buena salud mental gusta de la sensación de hacer las cosas mal, esa condición que se convierte en molestia.
Bueno, entonces los desarrolladores odian probar manualmente. ¿Qué más?
Los desarrolladores odian probar código escrito antes de la prueba, porque el código escrito así, en general, es difícil de probar porque él no fue hecho pensando en las pruebas. Si tenemos en cuenta que las pruebas automatizadas nada más son de los clientes de la aplicación, es difícil concluir que, incluso dentro de la aplicación, hacen un buen uso del código. Esto es lo que he visto suceder. Código difícil de probar es difíci de utilizar también. La solución es pensar en un diseño limpio, fácil de utilizar desde el comienzo, escribiendo pruebas para asegurar no sólo el funcionamiento sino también la utilidad del diseño. No termina ahí, usted crea una red de protección para evitar errores (en vez de tratar de encontrarlos sólo después de un largo tiempo) cuando un ambiente donde los cambios pueden ocurrir en forma segura.
Las pruebas manuales aún son necesarias en algún punto del sistema, pero siempre que sea posible, no acepte la incomodidad de pasar su tiempo así, esto simplemente no le ayuda a formar un ambiente libre de errores y bugs que matan la productividad de cualquier equipo. Tenemos que ir más allá de la cultura de encontrar errores sólo porque tienen un gran coste de tiempo de correción y de impacto en la moral del equipo. Si usted sufre de los males causados por la falta de pruebas, intente provocar cambios para bien en su lugar de trabajo, después de todo, a nadie le gusta jugar para perder.