Calidad del software y planes de pruebas

La calidad del software

La entrega de software sin errores no es posible.

A pesar de todas las pruebas y detección de errores en las distintas fases del desarrollo del software, tras incluso la promoción del código a producción, es inevitable detectar nuevos errores. Cada cliente es un escenario distinto, y cada usuario también, por lo que es imposible diseñar un plan de pruebas capaz de cubrir la totalidad de esos escenarios y prácticas que nos posibiliten una elevada calidad del software.

Podemos lograr 0 errores en base al plan de pruebas, pero no seremos capaces de diseñar un software que jamás traslade errores a los usuarios finales. Además, los desarrolladores, incluso sin detectar errores propiamente dichos, si revisaran mil veces el código, mil veces estarían en condiciones de producir un refinamiento de ese código, permitiendo la reutilización, refactorización, etc, con el riesgo implícito que supone esas tareas para la introducción de nuevos errores.

Aunque sea utópico, tratar de lograr esa utopía de 0 errores, dar una respuesta ágil y adecuada a la solución de esos errores, evitará generar desconfianza en clientes y usuarios.

Para ello es necesario poner a disposición de los usuarios herramientas de bug tracking o bien de herramientas de issue tracking (mejor ésta que la anterior) que permitan a éstos interactuar con los desarrolladores sobre los distintos incidentes y errores que van encontrando. Por supuesto, solo si el cliente ve que esas incidencias poseen tiempos de respuesta ágiles y adecuadas a su nivel de complejidad, éste depositará confianza en el software y en la empresa desarrolladora.

Precisamente para ayudar al cliente a la resolución de dudas, a su formación, a la consultoría y consecución de los mejores resultados en el uso del software, a la anticipación en la corrección de bugs, etc., es necesario recibir una contraprestación económica por ello.

Planes de pruebas

Eliminar/reducir los planes de pruebas es sinónimo de fracaso.

La entrega del software sin haber pasado las diferentes tipos de pruebas (unitarias, funcionales, de estrés, …) quizá consiga cumplir con la fecha de servicio, sin embargo, es seguro que ocasionará retrasos en la fase de go-live, cuando no graves problemas e incluso la retrocesión del proyecto.

Las distintas pruebas tienen por objetivo la detección de esas incidencias, pues en la fase de producción los errores suelen provocar problemas mayores y efectos colaterales indeseables.

No es la primera vez que me sucede tras un arranque tener que realizar procesos de reconstrucción de datos. Los propios errores generan información y datos inconsistentes que a posteriori hay que «regenerar» para dotarle precisamente de esa consistencia necesaria. Imaginemos un error en un proceso productivo que realiza movimientos de almacén. Un pequeño error no detectado a tiempo puede provocar movimientos de inventario incorrectos que posiblemente no sean detectados en el momento, sino días (o incluso meses) después.

Esto suele ocasionar una pérdida de rentabilidad importante en el proyecto, pues al coste de detectar y rastrear el error, suele seguir su corrección y a continuación la reconstrucción de los movimientos.

En definitiva, el resultado puede ser desastroso, tanto para el proveedor por el coste económico adicional incurrido y la pérdida de imagen, como para el cliente, por los errores que le pueda suponer una información incorrecta y el tiempo (igual a coste económico) dedicado a detectar y/o corregir la información.

Las pruebas manuales y automáticas no deben ser excluyentes, sino complementarias.

Las pruebas automáticas están pensadas para casos donde el software sufre constantemente múltiples cambios y donde las pruebas están diseñadas para ser repetitivas y reproducibles. Sin embargo, las pruebas manuales están más orientadas a pruebas de funcionalidad específica desarrollada.

Podríamos decir que es preferible las pruebas automáticas cuando principalmente se den algunos de estos factores:

• Es necesario repetir las pruebas en múltiples ocasiones.
• Cuando conviene realizar el esfuerzo para automatizar. Si hacerlo manualmente puede suponer 2 horas y preparar un programa para ejecutar automáticamente las pruebas supone más tiempo, no valdrá la pena el esfuerzo.
• El número de escenarios es muy amplio.

En caso contrario, será conveniente realizar un plan de pruebas manual.

(En el Master en Software Libre de Gestión: Open Source & ERP II, estamos analizando situaciones como la que aquí acabamos de mostrar).

Autor: Sergio Martínez

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly

Email