¿Son realmente necesarias las pruebas de testing en el desarrollo del Software?

Parece una pregunta obvia, lógica y recurrente, muy recurrente, quizás demasiado…, pero si esta pregunta sigue siendo recurrente y sigue apareciendo en libros, charlas de metodologías y buenas prácticas, videos, blogs o en discusiones en redes sociales, debe ser (digo yo) porque por alguna razón no todo el mundo puede hacerlas o sencillamente, no le da la misma importancia a las pruebas de testing.

Existen muchas empresas y desarrolladores que siguen desarrollando Software sin hacer pruebas de testing, o haciéndolas a medias, que para el caso es lo mismo con el hándicap de que nos estamos engañando a nosotros y a nuestros clientes, y perdiendo un tiempo estúpido haciendo algo que no sirve para nada a excepción de hacernos creer que hacemos más o menos bien.

Pero la pregunta clave como decía es si las pruebas de testing son realmente necesarias o no.
Yo tengo mi propia opinión que voy a exponer, pero al final de la entrada hago una seria de preguntas para aquellas personas que no opinan igual o que quieran dejar sus comentarios al respecto.

De hecho, cuando lanzas esta pregunta normalmente la mayoría de las personas afirman que por supuesto lo son.
Pero en muchas empresas no se justifica esto sobre todo de acuerdo a los costes, ya que eso significa incrementar los mismos y decirle a nuestro cliente que el desarrollo que costaba x va a costar x + y.
El temor a que el cliente se de la vuelta y vaya a otro proveedor existe y es humano.
También a veces, nos interesa trabajar con el cliente abc y para ello, debemos asumir ciertos riesgos y ciertas pérdidas.

¿Pero merece la pena realmente trabajar con un cliente que prima la baja calidad y nos supone un elevado riesgo?.
Pues si es lo que el cliente quiere y a nosotros nos interesa trabajar con él, parece lógico que echemos a un lado las pruebas, desarrollemos con un mínimo de calidad, cerremos los ojos y tiremos para adelante.

Otro incremento de costes es cuando en el mismo proyecto incorporas personas de diferentes niveles y perfiles, dónde lógicamente un desarrollador experimentado tendrá una tarifa más alta que otro desarrollador con menos experiencia.
Si el cliente tiene un presupuesto ajustado, podemos cerrar los ojos nuevamente y tirar para adelante o hacerle entender ciertos detalles de suma importancia.
Una vez más, podemos estar dispuestos a querer bailar con la persona más fea de la fiesta, pero debemos asumir los riesgos que esa empresa entraña.

Nuestra obligación (a veces no sencilla) es la de intentar convencer a nuestro cliente de lo que basándonos en nuestra experiencia entendemos como importante y de explicar lo que suponen los riesgos en los que incurrirá nuestro cliente de no variar su planteamiento.

Para aclarar todo esto un poco más, voy a quitarme por un momento la gorra de programador de Software y me voy a poner la gorra de otras profesiones según el caso para explicar mejor todo esto.

Hablando de costes en el desarrollo Software, tener un equipo que cubra diferentes perfiles es lo habitual.
Desde luego, cuanto mayor es el nivel de los profesionales, mejores resultados teóricos obtendremos, pero eso incrementa los costes lógicamente.
Sin embargo, tener un equipo mixto enriquece no sólo a la empresa que nos encarga el trabajo sino al propio equipo.
Todos los desarrolladores necesitamos mentores que contribuyan, corrijan, faciliten y ayuden a otros desarrolladores más noveles en su crecimiento como programadores, porque lo normal es que el desarrollo del Software tenga problemas que deban ser solucionados de forma ágil y eficiente.
Ejemplo:
Imaginemos que vienes a operarte de apendicitis al hospital.
Te puede operar el cirujano jefe por un coste determinado, a priori algo elevado como es lógico.
También te puede operar Manolo, un tipo muy simpático y con muy buena planta y actitud que acaba de aprobar el MIR y que ha entrado ayer a trabajar al Hospital. Manolo te cobrará la mitad que el cirujano jefe ya que va a realizar una de sus primeras intervenciones contigo y su experiencia no es la misma como es lógico.
Como término medio, Manolo también te podría operar con el cirujano jefe supervisando parte del trabajo. El coste estaría entre medias de los dos anteriores ya que el cirujano jefe sólo estará una pequeña porción del tiempo supervisando a Manolo. Pero la mayoría del peso de la operación la hará Manolo.
Lo siento por Manolo que no me ha hecho nada, pero a no ser que seas masoca, dudo que te interese que te opere Manolo únicamente e irías al modelo de Manolo con el cirujano jefe, o directamente no te la jugarías e irías directamente a que te operara el cirujano jefe.

Pues aunque parezca mentira, muchas empresas quieren que los desarrollos de Software los hagan “Manolos” nada más.
Luego llegan las lamentaciones y el rechinar de dientes.

Y hablando de costes y justificación de las pruebas de testing en sí voy a poner otro ejemplo.

Imaginemos que fabricamos coches.
Hagámonos unas sencillas preguntas.
¿Estaríamos dispuestos a fabricar un coche para nuestro cliente que no haya sido probado?.
¿Tendríamos la tranquilidad de entregar a nuestro cliente un coche del que no conocemos su fiabilidad, rendimiento, etc?.
¿Estaría nuestro cliente a admitir esto para ahorrarse un dinero?.
Si la respuesta es sí, nuestro cliente es un temerario y nosotros también.
Vamos… que una vez entregamos las llaves del coche, si nuestro cliente nos dice que si nos montamos con él, seguro que buscamos una excusa para no hacerlo.
Evitar ese tipo de clientes nos ahorrará a la larga muchos problemas, porque cuando haya problemas, nunca admitirá su error y siempre echará la culpa a quién hizo el Software afectándonos a nuestra reputación.

Llevando todo esto con ejemplos más orientados al desarrollo de Software en sí, imaginemos que vamos a hacer un Software que manipula planchas de oro que tienen un coste de 800 € cada plancha de oro.
¿El cliente daría por bueno un Software que va a manipular ese delicado y costoso material sin estar seguro de que no va a provocar problemas serios que generen pérdidas millonarias?.

Sé que vivimos en un mundo competitivo.
La competencia es bastante feroz, y muchas empresas proveedoras de servicios bajan sus tarifas incluso por debajo de los márgenes con tal de ganar cuota de mercado.
Pero estas prácticas son pan para hoy y hambre para mañana.

El testing nos permite encontrar errores y bugs durante la fase de desarrollo y antes de llevar nuestro Software a la fase de producción.
Se sabe a ciencia cierta, que encontrar y resolver un bug que se encuentra en la etapa de desarrollo de Software es cerca de 80 veces más barato y rápido que hacerlo cuando el Software está publicado y en el mercado.
Todos los que tenemos un poco de experiencia seguro que tenemos anécdotas de esto que acabo de decir.

Una buena estrategia de testing nos ahorrará muchos problemas y muchos disgustos, tanto a la empresa encargada de desarrollar el Software como al cliente.
Querer clientes satisfechos de nuestro trabajo debe ser un objetivo a cumplir siempre.
Si el cliente no quiere las pruebas porque quiere ahorrarse el dinero, debe ser consciente de los riesgos que esto entraña, y deberíamos hacerle firmar una claúsula de contrato que nos exima de toda responsabilidad en el caso de que se produzca algún error grave derivado de la ausencia de pruebas de testing.
Esta claúsula que indico hace que muchos clientes se lo piensen, porque prácticamente ninguno la aceptará.
Pero para la empresa que desarrolla Software, puede provocar en el futuro cercano problemas legales serios que a veces terminan incluso en los tribunales de justicia.
Debemos asumir que algunos clientes se echarán atrás tras comentar estas cosas y buscarán otro proveedor diferente con el que trabajar.
Y sólo los clientes serios, responsables y coherentes, no pondrán duda alguna a trabajar de esto modo.

Alguno me puede decir que no es lo mismo un desarrollo Software que otro, y cierto es que así es, pero también es cierto que detrás de todo esto hay una palabra:

CALIDAD

Si alguien no quiere desarrollo de calidad, es normalmente porque ese Software inicialmente no está justificado.
A veces lo está, como el desarrollo de una PoC o Proof of Concepts (Pruebas de Concepto en nuestra lengua), u otros desarrollos muy puntuales, pero hablando de desarrollos de Software de cierto tamaño, envergadura y profundidad, desarrollar sin pruebas es una temeridad como estoy exponiendo.

Las entregas deben cumplir los propósitos encomendados cumpliendo unos estándares mínimos de calidad.
Debe ser fiable, rápido, eficiente, y debe facilitar su mantenimiento.

Cuando llevemos algo a producción, debemos estar confiados en su funcionamiento.
Si por debajo de la mesa estamos cruzando los dedos, tenemos un problema serio, y tarde o temprano dará la cara y nos la partirá.

Los costes que se incrementan al propio desarrollo del Software en sí por incluir testing están SIEMPRE justificados.
Es más, yo que he estado trabajando como consultor y en empresa final que recibía ofertas de consultores, admito que una empresa de Software que me presenta un presupuesto de desarrollo sin incluir una partida de testing me hace sospechar.
Esta es la clave.
El testing no es un ente separado que flota en el aire y que podemos usar o no en el desarrollo del Software como si fuera el extra de un coche. Debe venir de serie. Forma parte de él y debe ser una parte indivisible del mismo.

Si el cliente se la quierer jugar sin incluir el testing, que lo haga, pero debemos ser sinceros con él y exponerle los riesgos a los que está expuesto.
Es como si un cliente comprara un coche que no llevara de serie el freno de mano.
Si aparca todos los días en una cuesta y pone una marcha, el coche el principio no se moverá.
Si gira la rueda y pega con el bordillo, tampoco se moverá.
Pero no podemos asegurar que el coche se vaya cuesta abajo un buen día.

Como digo, evidentemente podemos desarrollar Software sin testings, pero no me montaría en una cápsula espacial acoplada a un cohete que nunca fue probado.
Dicho de otro modo, si fuera el cliente, no pondría en producción algo del que no tengo claro que vaya a funcionar como se espera o que vaya a fallar en un momento dado inesperado.

Una de las leyes de Murphy que debemos comentar siempre a nuestros clientes dice que si algo puede salir mal, saldrá mal.
En desarrollo de Software también.
Incluso el testing en sí, no evita que eso pueda ocurrir, pero minimizaremos esa posibilidad enormemente.
Testing no significa 0 errores, significa tender a 0 esos errores que es diferente.

Para finalizar, dentro del abanico de las pruebas de testing me gustaría recalcar las que a mi juicio personal son las dos principales que deberíamos tener marcadas en rojo en nuestra guía de ruta del desarrollo del Software.
Las pruebas unitarias y las pruebas de integración.

Las pruebas unitarias nos permitirán probar unitariamente las rutinas, métodos y lógica de Software que estamos desarrollando.
Las pruebas de integración nos permitirá unir todas esas partes que unitariamente funcionan tal y como esperamos y ver que su comportamiento en conjunto, sigue siendo el esperado.

Algunos desarrolladores que encuentran un bug en una de las pruebas unitarias, corrigen ese método o porción de código, y vuelve a pasar la prueba unitaria que daba error hasta que pasa, obviando un principio clave en testing, que es que si una sola prueba unitaria falla, debe darse por inválido todo el modelo de pruebas, teniendo que empezar de cero todo su conjunto una vez corregimos el bug detectado.
Por lo que hacer testing no resuelve el problema de la calidad, simplemente nos ayuda a resolverlo.
Como hagamos ese testing es clave también.

A pesar de todo lo que comento, puede ser que a lo mejor no estés de acuerdo conmigo, así que pregunto en alto para conocer otros puntos de vista diferentes que justifiquen otros planteamientos.
¿Tú ves justificable que no se hagan pruebas de testing en los desarrollos de Software?.
¿En qué escenarios ves que las pruebas de testing no son necesarias y porqué?. ¿Qué justificación das?.

Happy Coding!