Estimar nuestras pruebas de forma sencilla.

Cuando hablamos de estimar pruebas, sabemos que no es una de las tareas más sencillas que podemos hacer, más que nada, porque son muchos los factores que afectan a ello.






Uno de los factores que más cohíben una estimación son las fechas, que ya suelen estar marcadas y nos hace que nos tengamos que ajustar a tiempos predefinidos y encajados en ciclos de desarrollo y de vida del producto que queremos probar.

Existen una serie de técnicas que podemos poner en práctica para que podamos estimar, más o menos, de una manera coherente y acertada, pero siempre cogiéndolo con pinzas.

Si estamos trabajando en un entorno Agile, para estimar, lo primero que tenemos que tener son las historias de usuario o las especificaciones funcionales, libre de dudas y con toda la información posible para determinar nuestro plan de pruebas o al menos, su esqueleto.

Si, por el contrario, existen dudas ya sean funcionales o a nivel técnico, debemos de mantener las conversaciones necesarias para que todo quede claro.

Una vez tengamos ese punto claro, que quizá es el más importante, debemos de tener unos porcentajes de aumento sobre lo que nos lleve la simple ejecución de las pruebas. Estos porcentajes deben de darse utilizarse con el análisis inicial de las pruebas, la obtención de los juegos de datos, la posible instalación del entorno (si no la realiza el equipo de DevOps), la propia ejecución y todo el ciclo de vida de los defectos.

Tras ello, también podemos tener tiempos de periodos de gracia o garantía sobre lo que se ha puesto en producción, además de las pruebas de regresión mínimas entre despliegues.

La primera etapa, como ya hemos comentado, es el análisis de los requisitos y el diseño del esqueleto del plan de pruebas, cosa bastante complicada de estimar, pero usando unos porcentajes, podemos determinar que nos llevará un 5% de las jornadas que lleve la especificación de los mismos. También es cierto, que, con los años y la experiencia, esto suele salir solo y ya solo con ver el documento por encima, ya puedes determinar lo que te va a llevar todo este trabajo.

Si hablamos de la obtención de un juego de datos coherente y adecuado para la realización de las pruebas, es casi “impepinable” el hablar de porcentaje, ya que dependerá de donde se saquen los datos, como serán de complejas las consultas y cual es la cantidad de casuísticas que hay que simular para realizar las pruebas completas.

De cara a estimar la ejecución de los casos de prueba, siempre nos solemos fijar en la misma premisa, tomar una media entre el caso de prueba más largo y el menor, dando como resultado, habitualmente unos 6 o a 10 minutos máximo, posibilitando que una batería de unos 70 u 80 casos se pueda realizar en 3 jornadas (siendo los casos de prueba medios y con una complejidad normal).

También, se puede realizar una métrica con una primera ejecución exploratoria, haciendo un pequeño reconocimiento a la aplicación y verificando su complejidad, de esta manera, sabremos, a grandes rasgos, el tiempo de media que nos puede llevar la ejecución de los casos de prueba.

Hablando sobre la gestión completa de los defectos, dependerá, habitualmente de la cantidad de ellos que encontremos en las pruebas, pero haciendo una media básica, debemos de aumentar al tiempo de ejecución un 15% de apertura, reprueba y cierre de defectos. Esto, lo suelo detectar ya que, con una estimación muy a alto nivel y poniéndome en el peor de los casos (si el desarrollo se ha realizado adecuadamente) suelen fallar un 30% de los casos de prueba.

Del resto de aproximaciones, debemos de tomar las mismas técnicas, aumentando en porcentajes con nuestras experiencias pasadas, ya sea, en las pruebas de regresión al poner en producción o en otras tareas habituales en nuestro trabajo.

Lo esencial, es que podamos ir valorando diferentes tiempos que aumentarán o disminuirán en base a las entregas, sprint o ciclos de trabajo y que nos darán, poco a poco, información mucho más veraz sobre tiempos y donde irnos acercando, de manera más adecuada a la realidad de nuestro proyecto y de los futuros que podemos probar.

























0 Comentarios