Calidad de software

La calidad del software es una preocupación a la que se dedican muchos esfuerzos. Sin embargo, el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.

En el desarrollo de software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es alta.

Son características propias del software, aquellas que tu quieres controlar y asegurar. El software es un producto inmaterial que no se fabrica, tampoco se degrada físicamente, pero sí se desarrolla. El software puede tener errores e incidencias, pero no son similares a las de cualquier equipo de carácter físico.

La calidad del software se encuentra casi a la par de la calidad tradicional, ligeramente detrás, debido a que la calidad tradicional tiene varias décadas de historia, mientras que la calidad de software tiene entre 50 y 30 años de haber surgido.

El software necesita ser actualizado.

Es consecuencia del proceso de aseguramiento de la calidad, pero nunca es el objetivo final. La calidad de software no se certifica, lo que se certifica, son los procedimientos para construir un software de calidad. Los procedimientos deben ser correctos y estar en función de la normalización (ISO 9000, CMMI, Moprosoft, etc.).

Pone a disposición de un auditor o certificador los procesos internos, de forma que este indique si cumple o no la normativa al 100%, se audita el sistema. Si los resultados son positivos, se emite la certificación, y cada cierto tiempo se tiene que renovar. La certificación es costosa, como consecuencia de los costes que ocasionan la lejanía y el tiempo de duración de proceso (aprox. 6 meses). Finalmente se certifican la empresa, y la metodología para el desarrollo de la aplicación.

En el software, lo que se mide son atributos propios del mismo, se descompone un atributo general en otros más simples de medir, a veces se mide bien o mal, ya que la descomposición del atributo genérico de calidad en otros sub-atributos, se torna irreal, se mide con datos estadísticos no avalados, es imposible decir que la medición se hace en forma correcta.

El concepto de medida va de más a menos, va de lo general a lo concreto, y lo concreto es asociado a la métrica, esta combinación te daría el nivel de calidad, o seguridad de tu producto. Las ciencias bien estructuradas, se basan en medidas bien tomadas con base en la matemática.

Esta es una tarea normalmente en exclusiva de los desarrolladores. Pero sin ella los bugs se propagan como una plaga.

Los tests unitarios son la primera barrera de control contra posibles bugs. Son la base del test driven development, si se quisiera seguir ese proceso. Agilizan el trabajo al poder cambiar partes del código y comprobar los fallos rápidamente. Son ejemplos para los nuevos desarrolladores que se añadan al proyecto.

Algunas ideas contrarias a los tests unitarios, se basan en que un buen diseño, o una buena planificación, arregla muchos más problemas que los detectados por este tipo de tests. Aunque el diseño sea fantástico, no puedes asegurar que el código funciona sin estos tests, y dependerías de otras pruebas a más alto nivel.

Los tests de integración, son los que verdaderamente comprueban que el sistema está funcionando. Unen partes del sistema y comprueban que encajan sin problemas. Son la base del behaviour driven development, junto con los tests funcionales. Los tests unitarios no tienen en cuenta elementos tan importantes como los accesos, la base de datos, o peticiones de red. No son suficiente para comprobar que el comportamiento es correcto.

Gracias a este tipo de tests podemos encontrar bugs directamente en los pull requests, sin necesidad de pasar regresivos relacionados con esa parte del producto. Hacen que el sistema sea fiable, pudiendo confiar en las partes protegidas por estos tests, ya que tendrán el comportamiento deseado al ser llamados por otros componentes. Adicionalmente, protegen a los grupos de desarrolladores, para que el código de otros componentes no les sorprenda de formas desagradables.

Al utilizar un lenguaje como gherkin, para escribir este tipo de pruebas, se consigue además una documentación extra sobre el funcionamiento del sistema. Pudiendo hallar rápidamente, qué está cubierto por los tests, y qué no.

Son un paso más allá de los tests de integración, y tratan de probar el sistema como lo haría un usuario. Aquí entra especialmente la automatización de interfaces gráficas. Son las pruebas funcionales que más mantenimiento necesitan, y las más lentas.

Sin embargo, los beneficios son similares a los anteriores tipos de pruebas. Protegen contra interfaces fallidas, y quitan trabajo a la hora de hacer pruebas manuales. Son especialmente útiles al configurarlos y prepararlos, para ser ejecutados en todos los entornos en los que se distribuye o se ejecuta la aplicación. Por ejemplo, en los diferentes navegadores soportados, si la interfaz a probar fuera un entorno web.

Sin este tipo de tests estamos condenados a probar manualmente las interfaces, pudiendo dejarnos en el tintero posibles combinaciones. Suelen ser los mejores para las pequeñas suites de smoke tests.

No se puede medir la calidad del software de forma correcta debido a su naturaleza, la certificación se da a los procesos de desarrollo, no al software en sí, el correcto desarrollo de los mismos, garantizaría un buen software. No se puede medir al software como tal, sino los atributos que lo conforman, y tales métodos de medida deben ser exactos.

El usuario final, mide la calidad del software según lo que tenga, o no. Es en ese sentido que la calidad del software depende de quien la juzgue. El hecho de que una empresa tenga certificación en calidad de software, no garantiza que su software sea de calidad.

---