ERP

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.

calidad_software

Ver fuente

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).

Recibe nuevos artículos mediante suscripción por e-mail, RSS o Feedly
Seguir en Feedly
 
VN:F [1.9.22_1171]
Rating: 4.0/5 (1 vote cast)
Calidad del software y planes de pruebas, 4.0 out of 5 based on 1 rating

Sobre Sergio Martínez

Dirección desarrollo e implantación ERP en Daemon4 Socialmedia, TIC, IDi, e-commerce, 2.0... Blogger en https://mundoerp.com

4 comentarios

Comentar

Su dirección de correo electrónico no será publicada.Los campos necesarios están marcados *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

x

Check Also

Integración de un CRM con otros sistemas de información

Al igual que el CRM, el ERP es un sistema que hace uso de una cantidad masiva de información, con la diferencia de que el CRM ejerce generalmente las funciones externas de cara al cliente, o front-office

Las pruebas de seguridad son una parte vital de la compra de software

Los proveedores de software están obligados a realizar pruebas de seguridad de su software, así como adquirir compromisos de solución de vulnerabilidades.

Métodos existentes para evaluación y selección de sistemas de gestión

Procedimientos o metodologías empleados para la evaluación y selección de un Sistema de Gestión

La automatización de los procesos: del ERP al workflow

Los sistemas workflow automatizan los procesos de negocio según el diseño inicial de dichos procesos. La accesibilidad y la integración son los aspectos fundamentales que lo diferencian de un BPMS

Como confundir la ofimática con el software de gestión empresarial

Hace unos días me contaba uno de nuestros comerciales su última experiencia en una presentación a ...