¿Cuándo parar de testear?

¿Cuántas veces nos habremos preguntado hasta qué punto debemos continuar haciendo testing? En un mundo ideal la respuesta a esta pregunta podría ser tan fácil como seguir realizando pruebas hasta que estemos completamente convencidos de que el sistema que estamos probando cumple todas las características de calidad que hayamos establecido con anterioridad.

¿Pero en qué escenario podemos seguir testeando hasta el pleno convencimiento de que el producto bajo test está facultado para ser liberado al público objetivo? Como muchos de vosotros estaréis pensando ahora, este escenario es poco plausible, principalmente por dos razones:

• El tiempo del que disponemos no es infinito: en la inmensa mayoría de ocasiones debemos trabajar con una fecha límite sobre la cual el producto en el que estamos trabajando deba pasar a la siguiente fase de desarrollo o a la vida real.  Podemos intentar burlar esa fecha “comprando” tiempo, pero, ¿cómo lo podemos hacer? La forma más sencilla sería añadir más recursos (ya sean más testers o herramientas) que nos puedan ayudar a ser más eficaces. No obstante, esta estrategia tiene dos importantes deficiencias:

*La primera, muy obvia, puramente económica: no siempre podremos añadir tantos recursos como queramos por un tema de coste.

*Obviemos la primera deficiencia: llegado a un cierto punto, ¿los testers que entren a formar parte del proyecto de calidad serán igual de eficientes que los que ya estaban? Muy probablemente no, y seguramente no sea porque no tengan la misma pericia, a priori, que los existentes.

• ¿Cuándo podemos estar completamente convencidos de que nuestro sistema está libre de errores? O lo que es lo mismo, ¿cuándo los riesgos de nuestro producto serán equivalentes a cero? Como muchos de vosotros habréis oído, una de las máximas dentro del mundo de QA es que “sin riesgo, no hay testing”, es decir: no podemos demostrar que un sistema está libre de errores. No obstante, es mucho más sencillo dejar constancia de la existencia de deficiencias en el objeto bajo test.

Y bien, sino podemos testear hasta satisfacer completamente nuestro apetito como testers, ¿cuál puede ser la métrica que nos defina en qué punto podemos parar?

Hay multitud de criterios de éxito que podríamos definir, pero los más comunes podrían recaer en uno de los siguientes 3 grupos de preguntas:

¿Han sido todos los casos de prueba planeados, ya ejecutados?

¡Mucho cuidado con simplificar la respuesta a esta pregunta! Para que este criterio tenga validez, debemos tener un nivel de confianza elevado acerca de nuestro plan de pruebas y de si representa fidedignamente el sistema que estamos probando, bajo todas las características de calidad que le sean aplicables (más info acerca de quality characteristics en TMAP).

Pongamos que nuestro plan de pruebas es realmente completo. ¿Es suficiente con ejecutar cada una de las pruebas una sola vez? Muy probablemente no, ya que es plausible que no todos los Test Cases tengan un resultado correcto a la primera. Pero, ¿van a resultar todas nuestras pruebas pasadas en algún momento? No podemos dar una respuesta tan tajante como a otras preguntas que mencionamos en este artículo, pero también es bastante posible que esto no ocurra; es decir, se aceptará una cierta tolerancia de casos con resultado fallido. No obstante, esta métrica, por sí sola, no nos dice mucho, sino va íntimamente ligada a la segunda de las preguntas que hemos definido como criterio de éxito de finalización de pruebas.

¿Está el número total de defectos y su severidad en un nivel aceptable?

Al fin y al cabo, uno de los productos más genuinos generados durante un proyecto de test son los defectos. Estos representan lo que no está funcionando acorde a los requerimientos establecidos del producto.

Volviendo al escenario ideal mencionado anteriormente, un sistema no sería publicado hasta que el contador de defectos estuviera a cero. Esta máxima, en muchas ocasiones, no suele cumplirse, y es por ello que establecemos unas ciertas métricas de tolerancia de fallos. Las más comunes suelen incluir el no desplegar ningún producto del cual cuelguen defectos severos, mientras que otros de más baja prioridad sí podrían permanecer (siempre y cuando establezcamos un camino común para su arreglo en posteriores versiones).

¿Cuál es la tendencia de hallazgo y arreglo de defectos?

Una actividad de gran utilidad en muchos aspectos de QA es la medición de tendencias. Una de ellas, puede ser la evolución en el número de defectos encontrados y arreglados en un periodo determinado. ¿Para qué nos puede valer esta métrica? Veámoslo con sencillo ejemplo: si detectamos que el número de bugs severos encontrados no decrece a medida que transcurre el proceso de test, es poco probable que nuestro sistema esté listo para ser publicado, ya que hay una alta probabilidad de que resten defectos importantes sin ser descubiertos. En este caso, será altamente recomendable continuar con el proceso de test, incluso aunque las fechas límites sean sobrepasadas.

Obviamente, podemos definir muchísimas más criterios de finalización de test. Algunos pueden venir más definidos desde el mundo del negocio, como ya pueda ser un presupuesto límite o un número máximo de horas, o desde el propio desarrollo, donde podríamos tener un ratio de horas de test en relación a las invertidas en programación. Cada proyecto o producto es un mundo, y cada uno puede tener su propia respuesta a la pregunta inicial de este artículo.

En SOGETI entendemos la importancia de obtener el máximo valor empresarial de tus sistemas de IT, conoce nuestras soluciones y servicios de Digital Assurance and Testing.

Isaac Álvarez Diz
QA Manager | SOGETI ESPAÑA