En Febrero del 2001 Elisabeth Hendrickson presentó "Better Testing, Worse Quality?" en una conferencia de la industria. Para resumirles ella enuncio que al invertir en testing, no se logra mejorar la calidad del software desarrollado. Al mejorar el equipo y los procesos de testing en una empresa, los desarrolladores pueden tender a relajarse al codificar, dejando de probar ellos mismos lo que desarrollan, defiriendo la detección de errores a los testers. Eso es un efecto negativo causado por la mejora. Ciertos defectos que los desarrolladores podrían haber encontrado salen a producción ya que cuantos más bugs existan, más salen a producción sin ser detectados. La solución propuesta fue reforzar el mensaje a los desarrolladores que prueben su trabajo, y esforzarse para prevenir defectos. La prevención puede lograrse mejorando los requerimientos, entrenando a los desarrolladores y aplicando buenas prácticas de desarrollo. Les dejo un mail de un tech lead a su equipo:As you know, there's a large, growing backlog currently in test.Development MUST produce bug-free code to ensure that the testers can pass our work quickly to release. Therefore, PLEASE test every component THOROUGHLY and dowhat you can to make sure it's bulletproof BEFORE requesting a build. Just because a project is in the queue for test doesn't mean you should leave it as-is - PLEASE consider performing a few hours of testing to ensure that it is working as well as possible!Thanks for your careful testing!!!
La moraleja de la historia nos enseña que invirtiendo en testing solamente no se mejora la calidad del software. Para lograr una mejora, hay que invertir para que los bugs puedan encontrarse y resolverse cuanto antes, como enuncian las metodologías ágiles hoy en día.
Si les intereso, les recomiendo que lean el paper de Elisabeth para entrar más en detalles sobre lo enunciado.
