[ez-toc]<\/p>\n
Quien haya tenido que realizar una\u00a0estimaci\u00f3n de pruebas<\/strong><\/a> de un proyecto de desarrollo de software<\/strong> sabe que no es un tema trivial, dado el alto n\u00famero de elementos a considerar. Los proyectos de pruebas<\/strong> de cada control de calidad suelen llevar aparejado, adem\u00e1s, un alto n\u00famero de imprevistos (recordemos que el objetivo de un plan de pruebas es localizar anomal\u00edas), lo que no ayuda precisamente a cerrar el esfuerzo del equipo de pruebas o los tiempos del proyecto.<\/p>\n En este post nos centraremos en tres formas de estimar las pruebas<\/strong>:<\/p>\n Esta es, en principio, la soluci\u00f3n \u00f3ptima. La dificultad con la que nos encontramos en este caso es la dependencia entre la existencia del modelo y de un proceso bien definido y maduro:<\/p>\n La definici\u00f3n de un modelo<\/strong>, al igual que la mejora del proceso asociado son actividades que se realizan de forma continua: tenemos que adaptarlo a nuevas problem\u00e1ticas, validarlo y, en el caso de identificar desviaciones entre el esfuerzo esperado y el real, localizar nuevos factores que puedan afectar y realimentar el modelo. Esta realimentaci\u00f3n puede realizarse de forma manual o aplicando principios de inteligencia artificial (machine learning).<\/p>\n No existe un modelo perfecto aplicable a cualquier organizaci\u00f3n. Al margen de la necesidad, ya comentada, de establecer un proceso de evoluci\u00f3n continua, es preciso considerar la informaci\u00f3n disponible en la organizaci\u00f3n en la que vayamos a aplicarlo, la fiabilidad de los datos o el peso de cada par\u00e1metro. En MTP, aunque disponemos de un modelo base que podemos usar como punto de partida, siempre recomendamos ajustarlo a la realidad de cada cliente.<\/p>\n Detr\u00e1s de las estimaciones que puede proporcionar un experto ingeniero de pruebas o un equipo de pruebas basadas en la experiencia de proyectos anteriores, suelen esconderse principios muy similares a los que hemos comentado en el apartado anterior. Se plantean cuestiones como las siguientes:<\/p>\n B\u00e1sicamente son los mismos puntos que valora un modelo, pero los datos est\u00e1n en la cabeza del profesional que hace la estimaci\u00f3n. El problema de esta metodolog\u00eda es que la estimaci\u00f3n depende del conocimiento de cada persona y de su disponibilidad. Pueden existir, por otra parte, factores subjetivos que influyan de forma puntual en la estimaci\u00f3n.<\/p>\n Con el objetivo de intentar reducir este factor subjetivo en el m\u00e9todo de estimaci\u00f3n, han surgido modelos de estimaci\u00f3n en grupo. El modelo Delphi de banda ancha (Wideband Delphi) <\/em>de Boehm y Farquhar, \u00a0o la Planificaci\u00f3n de p\u00f3ker (Planning poker o Scrum poker) de Grenning (aunque fue Cohn quien lo populariz\u00f3), aportan buenas pr\u00e1cticas asociadas a la realizaci\u00f3n del trabajo de estimaci\u00f3n por parte de un equipo. Seg\u00fan el modelo y variante utilizados (m\u00e9todo Delphi, Planning Poker o Grenning, puede o no haber un coordinador, incorporar un proceso iterativo de estimaci\u00f3n en el que el equipo pueda ampliar y mejorar su conocimiento del proyecto a estimar, utilizar valores preestablecidos (ej: Fibonacci)\u2026 Los par\u00e1metros a considerar siguen siendo similares a los vistos anteriormente, si bien la existencia de diversas perspectivas puede ayudar a la reducci\u00f3n del impacto en la estimaci\u00f3n de los factores subjetivos y a una r\u00e1pida optimizaci\u00f3n del modelo de trabajo.<\/p>\n El problema de las estimaciones basadas en la experiencia es la posibilidad (frecuente) de realizar c\u00e1lculos optimistas al centrarse en la estimaci\u00f3n te\u00f3rica sin considerar el peso de los imprevistos. Suele ser buena idea considerar la incorporaci\u00f3n de un porcentaje que sirva para cubrir dichos imprevistos.<\/p>\n Esta modalidad se suele utilizar en situaciones concretas, como:<\/p>\n A la hora de estimar en estos casos, es posible plantear un porcentaje fijo (habitualmente entre el 10% y el 20%) que deber\u00e1 ser aplicado a par\u00e1metros como el tiempo o el coste del desarrollo, el n\u00famero de l\u00edneas de c\u00f3digo (ponderado por el lenguaje), el n\u00famero de puntos funci\u00f3n\u2026 Esta \u00faltima forma de medir el tama\u00f1o de la aplicaci\u00f3n (la de los puntos funci\u00f3n) es de las m\u00e1s precisas, pero no siempre est\u00e1 disponible el dato o la informaci\u00f3n necesaria para obtenerlo. En MTP<\/strong> disponemos de medios (tablas realimentadas de forma constante) que nos permiten pasar de l\u00edneas de c\u00f3digo a puntos funci\u00f3n o de puntos funci\u00f3n a coste.<\/strong><\/p>\n Lo que estamos haciendo es, b\u00e1sicamente, utilizar un modelo de estimaci\u00f3n m\u00ednimo y como tal deber\u00edamos tratarlo (salvo que la limitaci\u00f3n sea contractual). En la medida que est\u00e9n disponibles, se deber\u00eda tomar en consideraci\u00f3n alguno de los par\u00e1metros que hemos comentado previamente, como el alcance de las pruebas, la tecnolog\u00eda, el lenguaje, etc.<\/p>\n Para terminar, hay dos factores adicionales a considerar: el tiempo y el presupuesto<\/strong><\/a>. Si nos encontramos con limitaciones asociadas a dichos factores, deberemos considerarlos a nivel de alcance, centr\u00e1ndonos en lo cr\u00edtico y levantando riesgos.<\/p>\nUso de modelos<\/h3>\n
\n
\n
\n
Estimaci\u00f3n basada en la experiencia<\/h3>\n
\n
Porcentaje del desarrollo<\/h3>\n
\n