Una cobertura de código del 100% no tiene porque ser suficiente

Cuando el código está cubierto al 100%, muchas veces nos planteamos, porque hay gente que se dedica al probar el software que estamos realizando.
 

El planteamiento inicial, viene dado por herramientas tipo SonarQube, donde solemos dar por buena, una cobertura del 80% del código. Esto es un éxito total y un orgullo para los desarrolladores, pero, ni un 100% es suficiente.

Si tenemos una cobertura del 80%, incluso de un 100%, que es casi imposible de conseguir, lo asociamos a un código de alta calidad, a un código completamente probado y esto es totalmente engañoso. Una cobertura del 100%, no significa que la calidad sea alta, ya que las pruebas no pueden ser correctas, puedes estar incompletas o puede ser que les falten datos.

Cuando se realiza una prueba, si hay algún camino que no se cubre porque no tenemos toda la información o todas las casuísticas que realiza un profesional de QA, ya tenemos caminos sin probar de los que pueden salir fallos. Además, las pruebas no podrían verificar la funcionalidad del código, una ejecución de una batería de test, podría no ser suficiente. 

Una de las estrategias a seguir, es que las pruebas unitarias se centren en probar temas aparte de la calidad general, la experiencia de usuario y la aceptación, y que esto lo haga un tester, pudiendo hacer que las pruebas de código validen los datos. Esto hará que la funcionalidad pueda ser correcta y gracias a las pruebas del tester, también las requisitos.

Un problema de la cobertura del código, siendo o no, al 100%, puede ser que no cubran lo que esperamos o sean incorrectas, una prueba puede estar OK, pero puede estar ejecutándose sin probar absolutamente nada.

Las pruebas deben de ser efectivas, deben de ser valiosas y aunque tengamos un porcentaje alto, no quiere decir que el código esté probado totalmente. El valor que aporta del desarrollador es que tiene un control total del manejo de las excepciones y puede inyectar condiciones necesarias para probar nuestros errores, ya que el API es cosa suya.

Aunque en muchos foros todo tiende a automatizar, a pruebas de integración, unitarias, pero los tester son muy necesarios para revisar el software y asegurarse de garantizar la calidad total. El complementar las pruebas del desarrollador con las del tester, es el caballo ganador de la calidad, porque se identifican áreas que cada uno puede cubrir y puede optimizar, haciendo que la calidad total entre ambos, si puede ser un 100% real.