¿Debe saber testing un desarrollador?

mtp
Por mtp

La respuesta es sí, ya que las buenas prácticas de programación están relacionadas con el testing.

Basándose en la aplicación de técnicas de pruebas de caja negra, como clases de equivalencia, valores límite, pruebas basadas en estados o comprobación de lógicas de negocio por tablas de decisión, se comprueba el efecto exponencial del coste de las pruebas respecto de la complejidad de las soluciones técnicas.

Dada una funcionalidad, probarla puede suponer un esfuerzo significativamente alto si la solución técnica no está correctamente elegida. Otra conclusión que se puede obtener es que si duplicamos la funcionalidad de un software, su esfuerzo de prueba es mucho mayor que el doble (incluso puede ser hasta 4 veces mayor). El coste de las pruebas es exponencial respecto a la complejidad de la solución técnica

Analizando las técnicas de prueba de caja blanca de un curso de fundamentos del testing, podemos comprobar que cuando no se siguen determinadas prácticas de codificación, el número de casos de prueba que debería hacerse alcanza valores de varias decenas o, incluso, centenares por cada método o función. Un software medio (unos 500KLOC) podría necesitar varios cientos de miles de casos de prueba a nivel de desarrollador.

Si aplicamos técnicas de medida de eficacia de las pruebas, como puede ser la técnica más simple y básica de caja blanca que es cobertura de sentencias, de la que se derivan varios cientos de casos de prueba para un componente, podemos comprobar que es muy habitual que entre un 15% y un 30% del código no se prueba nunca. Es decir, aún si hacemos cientos de casos de prueba por componente en la versión más simple de las técnicas de prueba, hay una parte del código que pasa a producción sin haberse ejecutado nunca.

¿Realmente somos conscientes del esfuerzo y la problemática en materia de pruebas que generan nuestros diseños software?. Cuando los desarrolladores conocemos las técnicas y principios del testing comprendemos que:

  • Realizar diseños y soluciones técnicas sencillas disminuyen el coste de las pruebas.
  • Las recomendaciones de codificación reducen el tiempo de las pruebas.
  • Si probamos mientras codificamos, nuestros diseños son más robustos y fáciles de mantener.

Si deseas ampliar más información pincha en el enlace de la presentación completa: Testing para Desarrolladores