{"id":1655,"date":"2017-04-11T08:10:36","date_gmt":"2017-04-11T06:10:36","guid":{"rendered":"http:\/\/www.mtp.es\/blog\/?p=1655"},"modified":"2017-04-11T08:10:36","modified_gmt":"2017-04-11T06:10:36","slug":"debe-saber-testing-un-desarrollador","status":"publish","type":"post","link":"https:\/\/mtp.global\/es\/blog\/archivo\/debe-saber-testing-un-desarrollador\/","title":{"rendered":"\u00bfDebe saber testing un desarrollador?"},"content":{"rendered":"

La respuesta es s\u00ed, ya que las buenas pr\u00e1cticas de programaci\u00f3n est\u00e1n relacionadas con el testing.<\/h2>\n

Bas\u00e1ndose en la aplicaci\u00f3n de t\u00e9cnicas de pruebas de caja negra<\/b>, como clases de equivalencia, valores l\u00edmite, pruebas basadas en estados o comprobaci\u00f3n de l\u00f3gicas de negocio por tablas de decisi\u00f3n, se comprueba el efecto exponencial del coste de las pruebas respecto de la complejidad de las soluciones t\u00e9cnicas.<\/p>\n

Dada una funcionalidad, probarla puede suponer un esfuerzo significativamente alto si la soluci\u00f3n t\u00e9cnica no est\u00e1 correctamente elegida. Otra conclusi\u00f3n 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\u00f3n t\u00e9cnica<\/p>\n

Analizando las t\u00e9cnicas de prueba de caja blanca<\/b> de un curso de fundamentos del testing, podemos comprobar que cuando no se siguen determinadas pr\u00e1cticas de codificaci\u00f3n, el n\u00famero de casos de prueba que deber\u00eda hacerse alcanza valores de varias decenas o, incluso, centenares por cada m\u00e9todo o funci\u00f3n. Un software medio (unos 500KLOC) podr\u00eda necesitar varios cientos de miles de casos de prueba<\/b> a nivel de desarrollador.<\/p>\n

Si aplicamos t\u00e9cnicas de medida de eficacia de las pruebas, como puede ser la t\u00e9cnica m\u00e1s simple y b\u00e1sica de caja blanca que es cobertura de sentencias<\/b>, 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\u00f3digo no se prueba nunca<\/b>. Es decir, a\u00fan si hacemos cientos de casos de prueba por componente en la versi\u00f3n m\u00e1s simple de las t\u00e9cnicas de prueba, hay una parte del c\u00f3digo que pasa a producci\u00f3n sin haberse ejecutado nunca<\/b>.<\/p>\n

\u00bfRealmente somos conscientes del esfuerzo y la problem\u00e1tica en materia de pruebas que generan nuestros dise\u00f1os software?.<\/b> Cuando los desarrolladores conocemos las t\u00e9cnicas y principios del testing comprendemos que:<\/p>\n