La medida de Software Testing que creerás imposible...
¿Te imaginas poder saber cuántos defectos tienes que encontrar antes de iniciar tus pruebas? Normalmente las métricas de números de defectos se realizan cuando finaliza el proyecto o algunas veces se intenta dar un estimado cuando se han encontrado varios defectos durante las pruebas, pero en este post te mostraré una técnica para poder saber este número antes de iniciar el testing formalmente.
La técnica se llama “Captura/Re-captura”, esta técnica es principalmente utilizada para saber la población de animales en un hábitat controlado, por ejemplo, se puede utilizar para saber el número de peces en un lago; tomando este ejemplo como base, primero se hace la captura de una muestra de peces, estos se marcan y se dejan libres de nuevo, después de un periodo de tiempo en que los peces han sido liberados y se han esparcido de nuevo por todo el lago se hace una re-captura y con algo de estadística podemos saber el número aproximado de peces en el lago, incluyendo un margen de error; nosotros la utilizaremos para saber el número aproximado de defectos en nuestro sistema a probar, peces=defectos.
Lo primero que necesitamos es un ambiente “estable” para probar, digamos, al finalizar la codificación por parte de los desarrolladores en cierto punto, puede ser al momento de finalizar algun módulo, para poder tener un rango menor de funcionalidades que probar en vez de ejecutar todo un sistema integrado; con esto listo necesitamos al menos dos personas que son quienes harán la “captura / re-captura”, lo ideal es que estas dos personas tengan una experiencia bastante similar y el mismo contexto en el sistema a probar, mientras más se asemeje su perfil más confiable será esta estimación. Estos son los pasos a seguir:
1. Ambas personas deben de tomar un tiempo específico (por ejemplo, 4 horas) para realizar una sesión de pruebas en el sistema, tendrán que buscar defectos en la aplicación, se debe de definir los tipos de defectos que se buscarán, pueden ser los que el proyecto considere más importantes, o cualquier tipo de defectos, siempre y cuando ambas personas estén enfocadas en el mismo tipo de defectos, no hay limitantes en esta parte. (hay que tomar el menor tiempo posible en documentar el defecto, esta sesión no es para reportar defectos a desarrollo)
2. Una vez finalizado el tiempo se deben de contar los defectos que cada persona encontró y cuántos de esos defectos encontraron ambos, entonces podemos iniciar con el análisis estadístico; Aqui no tendremos que hacer una recaptura como tal, ya que al tener dos personas buscando defectos existentes en el sistema estamos haciendo dos muestras distintas que no afectan los datos entre ellos mismos, es decir, si una persona encuentra un defecto no haya nada que impida que la otra persona tambien lo encuentre... Estos serán los valores de nuestra ecuación:
D = Número total de Defectos
d = Número de defectos encontrados por la primera persona
e = Número de defectos encontrados por la segunda persona
r = Número de defectos encontrados por ambos
3. Imaginemos que la primera persona encontró 25 defectos (d), la segunda persona encontró 27 (e) y ambos encontraron los mismos 7 defectos (r), ahora el problema es encontrar el número total de defectos (D). Utilizaremos la siguiente formula:
4. Ahora haremos la sustitución de valores:
Esto nos indica que el número de defectos que tenemos es 90
Ahora, te podrían llegar a pregunta “¿Qué tan confiable es tu estimación?” pues muy fácil! Solo tenemos que aplicar la siguiente formula: (Ok, no se ve tan facil... pero si lo es!)
Sustituyendo valores:
Esto quiere decir que al menos encontrarás 50 defectos y como máximo 125, pero tu valor medio esperado será de 90, como se mostró en la primer formula.
Esta técnica, como lo mencione antes, es utilizada en TSP/PSP como una manera de poder dar un estimado de que tantos defectos encontraremos al comenzar nuestras pruebas y nos da un objetivo definido en que enfocarnos, hay que tomar en cuenta que el uso de TSP/PSP normalmente los procesos están sumamente bien definidos ya que este “framework” es utilizado para alcanzar niveles de calidad superiores a los definidos por el CMMI Nivel 5, siguiendo paso a paso el método y teniendo un coach TSP como apoyo. Para poder utilizarl esta técnica es necesario que el Project Manager y todo el equipo en general este consciente de su utilidad y que todos estén de acuerdo, ya que en un equipo con una metodología definida podría resultarle poca práctica, una pérdida de tiempo, etc. todo depende del proyecto, sin embargo puedes sugerirla como un punto de partida para poder definir los objetivos de tus pruebas y para saber desde el inicio el nivel aproximado de calidad del sistema que estarás probando, estoy seguro que a más de uno les parecerá atractiva esta métrica.