- Principio 1: Las pruebas revelan la presencia de bugs, no la ausencia de ellos
Probar reduce la probabilidad de que
existan bugs pero nunca se puede asegurar que no quede ninguno oculto.
Además, cada tipo de pruebas que
realicemos (de sistema, de integración, añadir auditorías de código…) son más
efectivas para detectar un tipo de bug.
- Principio 2: Es imposible probarlo todo
El flujo de control de un sistema
software no trivial como los que acostumbramos a utilizar en el día a día
contiene miles de decisiones. Estas decisiones se pueden combinar entre ellas
para dar lugar a una infinidad de posibles caminos. De entrada, probar todos
los caminos es un problema inabordable.
Y eso si no tenemos en cuenta la
prueba de requisitos no funcionales, como el rendimiento de un sistema ante una
exigente carga de usuarios, o requisitos específicos de seguridad (por ejemplo,
en un sistema bancario) para protegerse de usuarios malintencionados.
Todo esto hace necesaria una
estrategia de pruebas (un plan) y priorizar a partir de una gestión de riesgos
de calidad y de proyecto.
- Principio 3: Cuanto antes se comience a probar…mejor
Corregir un bug con una revisión en
la fase de captura de requisitos o en una prueba unitaria tiene un coste mucho
menor a lo que costará corregir este bug cuando se detecte en una prueba de
sistema, o peor aún, en una prueba de aceptación por el cliente.
En demasiadas ocasiones existe una
confianza excesiva en las pruebas de sistema, y todo el plan de pruebas (cuando
existe) se reduce a estas. Se confía en que todos los componentes que no se
probaron con una estrategia de pruebas unitarias y de integración se puedan
entender bien a unos días del hito de entrega (cuando corregir un bug ya es
demasiado caro, en lo que se denomina una prueba de integración “big-bang”).
Curiosamente estas malas prácticas se
realizan para ahorrar costes, y finalmente el coste de la no calidad cambia las
tornas: siempre se acaba pagando en unos costes de mantenimiento excesivos (con
caídas de la productividad del 50% según Capers Jones).
- Principio 4: Las aglomeración de defectos. ¡Los bugs siempre van en conjunto!
Entender esto es muy importante para
plantear una buena estrategia de pruebas: los bugs suelen ir en grupo. Se
concentran en determinados puntos de un sistema software, no manteniendo una
distribución uniforme a lo largo del mismo.
Conclusión: si se encuentra un bug en
un componente, es muy probable que haya más. Con lo que una posible estrategia
sería centrarse en mejorar las pruebas de aquellos componentes para los que se
han reportado un número mayor de bugs, para ser más eficaces a la hora de
cazarlos en fases tempranas.
- Principio 5: La paradoja del pesticida
La necesidad de ajustar continuamente
el plan de pruebas… porque según este principio un plan de pruebas va perdiendo
efectividad conforme se ejecuta sucesivas veces. Con lo que cada vez tenderá a
encontrar menos bugs… ¡lo que no significa que no hayan! (vuelve a leer el
primer principio). Se habla de paradoja del pesticida ya que estos matabichos
usualmente sirven para un tipo de bichos, pero una vez no queda ninguno del
tipo específico que mata el pesticida… ¡nadie dice que no hayan otros bichos
campando a sus anchas!
- Principio 6: Las pruebas se deben adaptar a necesidades específicas
Esto viene a enlazar con lo que he
comentado antes. Si el producto se centra en el ámbito de la seguridad se deberán
adaptar los casos de prueba para intentar forzar situaciones o posibles
escenarios no amistosos. Si se quiere probar una intranet donde los servicios
más vitales son los de imputación de horas y el de vacaciones, es lógico
centrarse en estos servicios y no invertir tiempo en otros componentes
infrautilizados. Además, hay que tener
en cuenta que los recursos en los proyectos son siempre escasos, con lo que en
el inicio del proyecto hay que preguntarse… qué estrategia debemos seguir para
encontrar y corregir lo antes posible los bugs en las funcionalidades de mayor
valor para nuestros usuarios.
- Principio 7: La falacia de la ausencia de errores
Para terminar, nos encontramos con la
satisfacción del usuario y con el hecho de que los usuarios elijan tu software
para resolver sus necesidades. Que se hayan corregido muchos bugs no significa
que finalmente el software sea un éxito. En ocasiones hay que primar un buen
time to market, para luego corregir los problemas de calidad que quedaron por
el camino. Y esto si se hace de manera consciente y con una buena estrategia, a
priori, no debe ser un problema.
No hay comentarios:
Publicar un comentario