• viernes, septiembre 21, 2018

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
Puedes compartir en ...

Related Posts

4 Comments

  1. Entornos y metodologías en la implementación de un sistema de gestión Mundo.erp | Tecnologías ERP
    28 junio, 2015 at 20:01 Responder

    […] cliente (alguna mejora funcional, la corrección de algún error, etc.), podría ser necesario el entorno de pruebas, aunque suele ser innecesario en este […]

  2. Estimaciones de los proyectos de implantación ERP Mundo.erp | Tecnologías ERP
    3 mayo, 2015 at 20:01 Responder

    […] Mejorar la calidad de los productos entregados. Realizar testeos con mayor profundidad requerirá más tiempo pero sin duda evitará errores en el futuro. […]

  3. Actualización del ERP a nuevas versiones Mundo.erp | Tecnologías ERP
    8 febrero, 2015 at 20:01 Responder

    […] se minimizan enormemente si el cliente está dispuesto a que se liberen las actualizaciones en un entorno de pruebas previamente y donde se pueda testear fielmente. Si se logra esto, el impacto del cambio se […]

  4. Pruebas de software Mundo.erp | Tecnologías ERP
    1 febrero, 2015 at 20:01 Responder

    […] …Continuación del artículo anterior ‘Calidad del software y planes de pruebas’… […]

Leave A Comment