{"id":165,"date":"2012-09-09T11:02:23","date_gmt":"2012-09-09T10:02:23","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=165"},"modified":"2013-01-05T11:02:52","modified_gmt":"2013-01-05T10:02:52","slug":"complejidad-y-esfuerzo-de-qa","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/complejidad-y-esfuerzo-de-qa\/","title":{"rendered":"Complejidad y esfuerzo de QA"},"content":{"rendered":"<p>En el <a title=\"Tama\u00f1o de aplicaci\u00f3n\" href=\"http:\/\/qualilogy.com\/es\/tamano-de-aplicacion\" target=\"_blank\">post anterior<\/a>, yo pregunt\u00e9 \u00ab\u00bfQu\u00e9 es una aplicaci\u00f3n de gran tama\u00f1o? &#8216;Y propus\u00e9 clasificar aplicaciones en tama\u00f1o &#8216;simple&#8217;, &#8216;medio&#8217;, &#8216;grande&#8217; y &#8216;muy grande&#8217; bas\u00e1ndose en diferentes medidas de n\u00famero de l\u00edneas de c\u00f3digo (LOC) o de n\u00famero de objetos .<\/p>\n<p>Esta semana, otro &#8216;quizz&#8217; del mismo tipo &#8216;\u00bfQu\u00e9 es una aplicaci\u00f3n compleja? \u00bfEs posible evaluar el esfuerzo de pruebas en funci\u00f3n de la complejidad de la aplicaci\u00f3n?&#8217; <!--more--><\/p>\n<p>Todos sabemos que la Complejidad Ciclom\u00e1tica de McCabe (CC) es el principal indicador para medir la complejidad, aceptado por todos, sin controversia como puede ser el caso de la m\u00e9trica LOC para la medici\u00f3n de tama\u00f1o. El objetivo de este indicador: medir el n\u00famero de caminos independientes en el c\u00f3digo fuente del algoritmo.<\/p>\n<p>Un ejemplo concreto, la siguiente regla: \u00absi factura &gt; 50, rebaja = 1%\u00bb. En pseudo-c\u00f3digo, esto se traducir\u00e1 de la siguiente manera:<\/p>\n<pre>IF Factura &gt; 50\r\n  THEN Rebaja = 1%\r\nELSE\r\n  Rebaja = 0%\r\nENDIF<\/pre>\n<p>El algoritmo para esta regla tiene dos caminos distintos por las dos partes de la condici\u00f3n: la factura da derecho a un descuento o no. Estos dos caminos son equivalentes a dos puntos de Complejidad Ciclom\u00e1tica.<\/p>\n<p>Ahora vamos a complicar esta regla, o m\u00e1s bien, agregar nuevas reglas: \u00absi la factura &gt; 500, 10% de descuento; si la factura &gt; 300, 5% de descuento; si la factura &gt;200, 2% de descuento.<\/p>\n<p>El pseudo-c\u00f3digo para los dados se convierte entonces en:<\/p>\n<pre> IF Factura &gt; 500\r\n   THEN Rebaja = 10%\r\n   ELSEIF Factura &gt; 300\r\n     THEN Rebaja = 5%\r\n     ELSEIF Factura &gt; 200\r\n       THEN Rebaja = 2%\r\n       ELSEIF Factura &gt; 50\r\n         THEN Rebaja = 1%\r\n         ELSE Rebaja = 0%\r\n       ENDIF\r\n     ENDIF\r\n   ENDIF\r\n ENDIF<\/pre>\n<p>He eligido (voluntariamente) la m\u00e1s compleja y menos correcta manera de escribir el pseudo-c\u00f3digo para estas reglas, con varios IF a\u00f1adidos. Pero no es el tema de este post.<\/p>\n<p>En este ejemplo, tenemos cuatro condiciones y un caso en el que no se cumple cualquier condici\u00f3n. O para decirlo de otra manera, hemos a\u00f1adido tres reglas adicionales al caso anterior y nuestra complejidad ciclom\u00e1tica es ahora m\u00e1s alta.<\/p>\n<p>Todas las herramientas de an\u00e1lisis de c\u00f3digo no calculan la Complejidad Ciclom\u00e1tica de la misma manera, por lo que el resultado puede variar (m\u00e1s o menos uno) pero de nuevo, esto no es el objeto de este post. Digamos que tenemos una CC igual a 5, lo que corresponde a cinco caminos distintos en el algoritmo, cinco valores diferentes para los objetos &#8216;Factura&#8217; y &#8216;Rebaja&#8217;.<\/p>\n<p>\u00bfDir\u00edas tu que se deben probar estos valores diferentes en una fase de QA?<\/p>\n<p>Si tu respuesta es positiva, entonces significa que la Complejidad Ciclom\u00e1tica es un buen indicador del n\u00famero de casos de prueba. Claro, si tienes una aplicaci\u00f3n con 10 000 puntos de CC, esto no significa que tienes que probar 10 000 casos diferentes, o incluso que la aplicaci\u00f3n no tendra defectos si se prueba todos los casos posibles. Pero por lo menos se puede calcular con mayor precisi\u00f3n el esfuerzo de QA, no el mismo cuando la CC ser\u00e1 de 2 000 puntos, 20 000 o 100 000 puntos.<\/p>\n<p>El &#8216;quiz&#8217; de esta semana tiene doble pregunta:<\/p>\n<ul>\n<li>\u00bfQu\u00e9 es una aplicaci\u00f3n compleja?<\/li>\n<li>\u00bfQu\u00e9 nivel de QA para qu\u00e9 nivel de complejidad?<\/li>\n<\/ul>\n<p>Os propongo los siguientes valores:<\/p>\n<h4 style=\"text-align: center\"><em><span style=\"text-decoration: underline\"><strong>Complejidad de la aplicaci\u00f3n en puntos de CC<\/strong><\/span><\/em><\/h4>\n<table width=\"643\" border=\"1\" cellspacing=\"0\" cellpadding=\"0\">\n<tbody>\n<tr>\n<td valign=\"top\" width=\"100\">\n<p align=\"left\"><strong>Complejidad<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p style=\"text-align: center\"><strong>Baja<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p style=\"text-align: center\"><strong>Media<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p style=\"text-align: center\"><strong>Alta<\/strong><\/p>\n<\/td>\n<td valign=\"top\" width=\"154\">\n<p style=\"text-align: center\"><strong>Muy alta<\/strong><\/p>\n<\/td>\n<\/tr>\n<tr>\n<td valign=\"top\" width=\"127\"><strong>Puntos de CC<\/strong><\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">6 000<\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">16 000<\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">50 000<\/p>\n<\/td>\n<td valign=\"top\" width=\"127\">\n<p align=\"center\">&gt; 50 000<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3><strong>Application poca compleja<br \/>\n<\/strong><\/h3>\n<p>Con menos de 6 000 &#8216;caminos&#8217; en la aplicaci\u00f3n, las pruebas unitarias por parte del equipo de proyecto deben ser suficientes para controlar la mayor\u00eda de los casos. Este presupone un buen conocimiento funcional de la aplicaci\u00f3n.<\/p>\n<p>Por lo general, las especificaciones no son muy formalizadas porque los desarrolladores est\u00e1n en contacto directo con los usuarios o sus representantes.<\/p>\n<h3><strong>Aplicaci\u00f3n moderadamente compleja<\/strong><\/h3>\n<p>Entre 6 000 y 16 000 puntos de CC, las pruebas unitarias se requieren, como antes, y son bastante numerosas para que el equipo del proyecto las automatiza con una herramienta. El tama\u00f1o del c\u00f3digo y el n\u00famero de casos de pruebas aumentan significativamente.<\/p>\n<p>El conocimiento de las especificaciones funcionales se reparte entre varios miembros del equipo del proyecto: empezamos a ver los desarrolladores especializados con alg\u00fan c\u00f3digo o diferentes m\u00f3dulos funcionales. Una etapa espec\u00edfica de pruebas de integraci\u00f3n es necesaria para verificar que el conjunto de las diferentes cadenas de componentes corresponde a las exigencias funcionales de los usuarios.<\/p>\n<h3><strong>Aplicaci\u00f3n compleja<br \/>\n<\/strong><\/h3>\n<p><strong><\/strong>Los umbrales pueden variar entre 16 000 y 20 000 puntos de CC para el l\u00edmite inferior y 50 000 y 60 000 puntos de CC para el l\u00edmite superior, seg\u00fan las tecnolog\u00edas o la arquitectura de la aplicaci\u00f3n o la frecuencia de evoluci\u00f3n del c\u00f3digo. Obviamente no hay un l\u00edmite espec\u00edfico, pero cuanto m\u00e1s nos acercamos a un umbral, m\u00e1s la estrategia de QA correspondiente ser\u00e1 aplicable.<\/p>\n<p>M\u00e1s all\u00e1 de 16 000 puntos (sobre todo m\u00e1s all\u00e1 de 20 000), la aplicaci\u00f3n es compleja. El tama\u00f1o del equipo de proyecto puede llegar a ser importante cuando las correcciones o los cambios son frecuentes.<\/p>\n<p>Adem\u00e1s de las pruebas unitarias y de integraci\u00f3n en el equipo de proyecto, es esencial llevar a cabo una fase espec\u00edfica de pruebas con un equipo dedicado de QA. La formalizaci\u00f3n de los casos de pruebas basandose en un documento de especificaciones funcionales es cada vez m\u00e1s necesaria cuando la complejidad se acerca al l\u00edmite superior.<\/p>\n<h3><strong>Aplicaci\u00f3n muy compleja<br \/>\n<\/strong><\/h3>\n<p>M\u00e1s all\u00e1 de 50 000 o 60 000 puntos, la aplicaci\u00f3n es muy compleja. Se necesitan herramientas para automatizar las pruebas unitarias, de integraci\u00f3n o de control de calidad. Las especificaciones funcionales deben estar siempre formalizadas antes de la fase de desarrollo.<\/p>\n<p>Conoc\u00ed a pocas aplicaciones m\u00e1s all\u00e1 de 100 000 puntos de CC, incluso en el mundo mainframe. Se encuentran generalmente en \u00e1reas con cambios reglamentarios frecuentes, por ejemplo tratamientos de c\u00e1lculo de subsidio familiar, con siempre nuevas reglas sin que se quitan las reglas anteriores.<\/p>\n<p>La mayor\u00eda de las veces, estos monstruos son la consecuencia de las derivas del management que ha permitido que la aplicaci\u00f3n se vuelva cada vez m\u00e1s compleja. Se encuentran en mercados que pasaron de un crecimiento r\u00e1pido y muy fuerte, lo que justifica cambios frecuentes en la aplicaci\u00f3n sin ninguna preocupaci\u00f3n por la deuda t\u00e9cnica, a un per\u00edodo de estabilizaci\u00f3n o de disminuci\u00f3n de cuotas de mercado y en una reducci\u00f3n de los presupuestos de TI, y imposible reducir esta deuda t\u00e9cnica por que no hay m\u00e1s dinero para una refactorizaci\u00f3n. Los intereses de esta deuda permanecen elevados para siempre.<\/p>\n<p>\u00bfQue opinas tu? \u00bfCrees que la medida de la complejidad es un buen indicador del esfuerzo de QA?<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>En el post anterior, yo pregunt\u00e9 \u00ab\u00bfQu\u00e9 es una aplicaci\u00f3n de gran tama\u00f1o? &#8216;Y propus\u00e9 clasificar aplicaciones en tama\u00f1o &#8216;simple&#8217;, &#8216;medio&#8217;, &#8216;grande&#8217; y &#8216;muy grande&#8217; bas\u00e1ndose en diferentes medidas de n\u00famero de l\u00edneas de c\u00f3digo (LOC) o de n\u00famero de objetos . Esta semana, otro &#8216;quizz&#8217; del mismo tipo &#8216;\u00bfQu\u00e9 es una aplicaci\u00f3n compleja? \u00bfEs [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"class_list":["post-165","post","type-post","status-publish","format-standard","hentry","category-qa"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/165"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=165"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/165\/revisions"}],"predecessor-version":[{"id":166,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/165\/revisions\/166"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=165"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=165"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=165"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}