Quien haya tenido que realizar una estimación de pruebas de un proyecto de desarrollo de software sabe que no es un tema trivial, dado el alto número de elementos a considerar. Los proyectos de pruebas de cada control de calidad suelen llevar aparejado, además, un alto número de imprevistos (recordemos que el objetivo de un plan de pruebas es localizar anomalías), lo que no ayuda precisamente a cerrar el esfuerzo del equipo de pruebas o los tiempos del proyecto.
En este post nos centraremos en tres formas de estimar las pruebas:
Uso de modelos
Esta es, en principio, la solución óptima. 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:
- Bien definido porque necesitamos tener claros los diversos elementos que puedan influir en el alcance de los trabajos, así como en el nivel de esfuerzo o duración asociados. Entre los parámetros que solemos considerar en nuestras estimaciones se encuentran:
- El tamaño del desarrollo: en principio, cuanto más grande sea el desarrollo, más pruebas deberían realizarse, aunque no es (no debería ser) el único factor a considerar.
- El nivel de riesgo: la criticidad y el impacto que pueden generar los defectos no localizados son elementos clave a la hora de establecer el esfuerzo (y el orden) de las pruebas.
- El alcance: es necesario determinar qué clase de pruebas se van a llevar a cabo (funcionales, de rendimiento, de seguridad…), si se va a probar la aplicación sobre un único navegador o sobre varios, si sobre un único dispositivo o sobre un conjunto de ordenadores, teléfonos y tablets con diversos SSOO y versiones…
- La tecnología (web, mainframe, SAP…): al margen de que hay tecnologías más difíciles de probar, que requieren más tiempo, esfuerzo o conocimiento, existen dependencias a nivel de herramientas que también pueden afectar.
- El número de sistemas involucrados. Un alto número de interfaces siempre supone una dificultad añadida.
- La calidad de los equipos de desarrollo, del encargado de los requisitos, de los equipos de pruebas: si quien diseña, desarrolla o prueba no domina la tecnología, no conoce las herramientas, no controla los sistemas afectados o no cuenta con una base técnica suficiente, tardará más y tendrá que repetir más de una vez alguna tarea.
- Maduro porque el proceso debe ser aplicado de forma sistemática por parte de los diversos participantes para poder asegurar que las actividades realizadas en distintos proyectos son consistentes y que los datos obtenidos son comparables. Como parte del proceso, las previsiones y los esfuerzos reales, así como cualquier información que pensamos que pueda afectar a dicho esfuerzo, ha de ser registrada en un histórico.
La definición de un modelo, al igual que la mejora del proceso asociado son actividades que se realizan de forma continua: tenemos que adaptarlo a nuevas problemáticas, 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ón puede realizarse de forma manual o aplicando principios de inteligencia artificial (machine learning).
No existe un modelo perfecto aplicable a cualquier organización. Al margen de la necesidad, ya comentada, de establecer un proceso de evolución continua, es preciso considerar la información disponible en la organización en la que vayamos a aplicarlo, la fiabilidad de los datos o el peso de cada parámetro. En MTP, aunque disponemos de un modelo base que podemos usar como punto de partida, siempre recomendamos ajustarlo a la realidad de cada cliente.
Estimación basada en la experiencia
Detrás 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:
- ¿Cuáles son las consecuencias si la aplicación se prueba poco o mal y surgen errores?
- ¿Qué confianza me generan los equipos de desarrollo o de pruebas?
- ¿Qué tamaño tiene el desarrollo a probar?
- ¿Qué tipo de problemas relativos a la calidad ha producido la aplicación (o alguna similar) en el pasado? ¿Cuáles han sido las causas?
- ¿Existe la posibilidad de que los requisitos estén mal definidos?
Básicamente son los mismos puntos que valora un modelo, pero los datos están en la cabeza del profesional que hace la estimación. El problema de esta metodología es que la estimación 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ón.
Con el objetivo de intentar reducir este factor subjetivo en el método de estimación, han surgido modelos de estimación en grupo. El modelo Delphi de banda ancha (Wideband Delphi) de Boehm y Farquhar, o la Planificación de póker (Planning poker o Scrum poker) de Grenning (aunque fue Cohn quien lo popularizó), aportan buenas prácticas asociadas a la realización del trabajo de estimación por parte de un equipo. Según el modelo y variante utilizados (método Delphi, Planning Poker o Grenning, puede o no haber un coordinador, incorporar un proceso iterativo de estimación en el que el equipo pueda ampliar y mejorar su conocimiento del proyecto a estimar, utilizar valores preestablecidos (ej: Fibonacci)… Los parámetros a considerar siguen siendo similares a los vistos anteriormente, si bien la existencia de diversas perspectivas puede ayudar a la reducción del impacto en la estimación de los factores subjetivos y a una rápida optimización del modelo de trabajo.
El problema de las estimaciones basadas en la experiencia es la posibilidad (frecuente) de realizar cálculos optimistas al centrarse en la estimación teórica sin considerar el peso de los imprevistos. Suele ser buena idea considerar la incorporación de un porcentaje que sirva para cubrir dichos imprevistos.
Porcentaje del desarrollo
Esta modalidad se suele utilizar en situaciones concretas, como:
- Si el esfuerzo en pruebas está limitado, preestablecido por normativa o por contrato.
- Si no se dispone de un mínimo de información acerca del alcance o características del proyecto.
A la hora de estimar en estos casos, es posible plantear un porcentaje fijo (habitualmente entre el 10% y el 20%) que deberá ser aplicado a parámetros como el tiempo o el coste del desarrollo, el número de líneas de código (ponderado por el lenguaje), el número de puntos función… Esta última forma de medir el tamaño de la aplicación (la de los puntos función) es de las más precisas, pero no siempre está disponible el dato o la información necesaria para obtenerlo. En MTP disponemos de medios (tablas realimentadas de forma constante) que nos permiten pasar de líneas de código a puntos función o de puntos función a coste.
Lo que estamos haciendo es, básicamente, utilizar un modelo de estimación mínimo y como tal deberíamos tratarlo (salvo que la limitación sea contractual). En la medida que estén disponibles, se debería tomar en consideración alguno de los parámetros que hemos comentado previamente, como el alcance de las pruebas, la tecnología, el lenguaje, etc.
Para terminar, hay dos factores adicionales a considerar: el tiempo y el presupuesto. Si nos encontramos con limitaciones asociadas a dichos factores, deberemos considerarlos a nivel de alcance, centrándonos en lo crítico y levantando riesgos.
Santiago Jaraba
Consultor Senior de Pruebas
Te puede interesar…
Conoce nuestro curso de requisitos y la formación especializada de MTP.