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.




0 Comentarios