Cada vez que alguien dice “no hay tiempo para testing” yo escucho “no me importa la calidad de esto que liberamos”. Acá encontré un artículo que está bien interesante sobre el tema, intentando ver cuáles son las causas que nos llevan a esa situación, como por ejemplo, malas estimaciones, proceso de desarrollo ineficiente, etc. Además, el mismo artículo intenta plantear algunas soluciones, como por ejemplo estimar bien (cómo no se me ocurrió antes ?) y tener en cuenta distintas consideraciones al momento de planificar.
Más allá de esto, que creo que puede ser muy útil leerlo, el “no hay tiempo” en la mayoría de los casos significa “estoy decidiendo no dedicar tiempo”.
En un contexto ágil por ejemplo, podríamos tomar la decisión de liberar menos historias, pero con mayor calidad. A la larga, eso va a aumentar nuestra productividad, ya que será menos necesario dedicar horas a soporte o mantenimiento correctivo. En un proceso tipo cascada, o más asociado a un contrato, no siempre es fácil cambiar la fecha de release, o cambiar los recursos o alcance. Seguro que ahí el problema fue de estimación, y muchas veces quizá hasta fue intencional, no considerando tiempo para testing como para que el proyecto sea de menor costo y así tener más probabilidades de ganar una licitación.
Por esto último, creo que hay un desafío muy grande para organismos estatales, o grandes empresas que se manejan con licitaciones para seleccionar a sus proveedores, como para que de algún modo se pueda pedir que lo que se entrega está bien probado y con buenas prácticas de desarrollo, y que cada uno de los que se postulan a la licitación consideren estas actividades en los costos. Así, evitaríamos sorpresas. Algo de esto estuve hablando al final de la keynote de Argentesting el año pasado, que podés ver el video acá, donde contaba cómo un enfoque de CI/CD con entregas frecuentes y revisiones de distintos factores de calidad puede ayudar en el proceso.
Lamentablemente, en nuestra industria si no se especifica claramente el nivel de calidad que se desea, no se asume por defecto. O peor, si no se especifica que es necesario que la calidad requerida esté probada, no se prueba, ya que no hay tiempo para probar.
Me encantaría escuchar/leer tu opinión.
La verdad que es una lástima que muchas veces se priorice sacrificar el tiempo que realmente se necesita para testear un producto a cambio de economizar o apurar la salida del mismo. Algo que sale rápido puede parecer más beneficioso en primera instancia, pero cuando empiezan a fallar cosas termina resultando no sólo más caro por todo el mantenimiento necesario, sino que además se pierde la imagen que la empresa necesita dar por no poder asegurar la confianza y seguridad que le transmitimos al cliente en términos de calidad y dedicación.