El software, como todo producto o servicio, no está ajeno a la evaluación de calidad por parte de sus usuarios y clientes. A pesar de ello, definir la calidad de un software no es tan sencillo como parece porque, ¿en qué hay que fijarse para determinarla?

‍

Cómo medimos la calidad de un producto habitualmente

Si quiero medir la calidad de una manzana, por ejemplo, basta con probar un bocado de la misma y, en base a características como su sabor y su textura, es posible determinar si la manzana es buena y la sigo comiendo, o es mala y la desecho (a menos que el hambre sea más grande). Claramente, las características de una manzana son pocas y fácilmente identificables. Subamos el nivel de complejidad, ¿cómo medimos la calidad de un automóvil?

Un automóvil tiene muchas más características que una manzana. De hecho, tiene muchas características, funciones y componentes que la mayoría de los mortales desconocemos. Aún así, hay un subconjunto de ellas fácilmente identificables, como la comodidad, la seguridad y el rendimiento, por ejemplo. En base a características como las anteriores, es posible determinar la calidad de un automóvil respondiendo a preguntas cómo ¿es cómodo para hacer un viaje de 2 horas?, ¿y para un viaje de 6 horas?; ¿tiene elementos o mecanismos que me ayuden a prevenir un accidente?, ¿cuenta con las condiciones de seguridad que me permitan evitar lesiones graves luego de un accidente?; y, la más clásica, ¿cuántos kilómetros rinde por litro?.

Dependiendo de las respuestas a las interrogantes anteriores, es posible determinar la calidad de un automóvil. Pero, dependiendo de los énfasis que haga cada persona, la importancia relativa de cada una de estas preguntas puede variar. Por ejemplo, para una familia con hijos puede ser más importante la seguridad que el rendimiento de un automóvil. De hecho, puede buscar responder otras preguntas, tales como ¿cuántas sillas de niño caben en la parte trasera? o ¿el maletero tiene suficiente espacio para guardar nuestro equipaje en caso de ir de vacaciones?. Preguntas muy distintas a éstas buscaría responder, por ejemplo, un joven soltero. Quien, supongamos, está más preocupado de los caballos de fuerza del vehículo y de su sistema de frenos. O su preocupación por el ambiente lo lleva a investigar sobre su nivel de emisiones contaminantes. Así, el nivel de calidad de un automóvil depende de la perspectiva de quien evalúe.

Medir la calidad de un software es aún más difícil que medir la calidad de un automóvil. Cómo ya se mencionó anteriormente, la calidad de un producto o servicio es subjetiva. Esto, dado que la evaluación de calidad depende de que tan bien satisfechas son las necesidades individuales de cada usuario o cliente. Puesto que un automóvil es un producto tangible (se puede ver y tocar), definir el conjunto de características de interés es un proceso relativamente sencillo. En un software, en cambio, los componentes visibles para un usuario (cómo botones, formularios e imágenes) no muestran la complejidad lógica y operativa que hay detrás. Apretar un botón puede significar el desencadenamiento de muchos componentes interrelacionados, desconocidos para un usuario. Al mismo tiempo, ejecutar una acción que parece sencilla puede traer consigo dificultades que sólo salen a la luz una vez que el desarrollador comienza a escribir el código fuente. Es por ello que un software, cómo producto intangible, requiere un trato especial en cuanto a la medición de su calidad.

‍

Factores a considerar

Lo primero, y más importante a considerar, es que la calidad puede ser medida desde diferentes perspectivas. En esa línea, en software se consideran dos tipos de calidad diferentes: la calidad interna y la calidad externa.

La calidad interna hace alusión a aspectos técnicos del software. Puede y debe medirse desde diferentes perspectivas, tales cómo rendimiento, calidad del código, deuda técnica, uso de recursos y escalabilidad, entre otras. Todo equipo de desarrollo debe evaluar constantemente la calidad del software que produce, dado que sin una buena calidad interna no puede existir calidad externa. Próximamente publicaremos otro artículo donde abordaremos en profundidad este tema.

La calidad externa, por su parte, es lo que ven, aprecian y perciben los usuarios de un software. Tiene como objetivo medir la percepción que los usuarios y/o clientes tienen del software en relación a diferentes perspectivas, tales como el cumplimiento de los objetivos de negocio, el valor que aporta al mismo, la usabilidad de la interfaz y la cantidad de defectos que posee. Al igual que con la calidad interna, la calidad externa debe ser evaluada constantemente. La diferencia es que, para lograr esto, es necesario que los usuarios puedan usar el software y así dar su veredicto. Para ello, existen una serie de herramientas que permiten medir la calidad externa desde diferentes perspectivas, sobre las cuales hablaremos en un próximo artículo.

Ya conocidas a grandes rasgos las formas en las que se mide la calidad de un software, planteemos el siguiente escenario: la empresa ACME está en medio de un proceso de transformación digital. Siguiendo una de las conclusiones obtenidas de tal proceso, se está desarrollando (con una empresa externa) un software que facilita y agiliza la labor de los vendedores con el objetivo de aumentar las ventas. ¿Cómo puede el gerente de la empresa ACME asegurarse de la calidad del producto software?

‍

Si todo es importante, nada es importante

La primera tentación en el desarrollo de un producto software es considerar que todas y cada una de las funciones son de vida o muerte y, por lo tanto, todas tienen el mismo nivel de importancia. Esto está lejos de ser cierto, y quienes conozcan el principio de Pareto no podrán estar más de acuerdo dado que en software también aplica la regla del 80–20. Así, es necesario focalizar el esfuerzo en la búsqueda de la máxima calidad posible en el 20% de las funcionalidades que aportan el 80% del valor de negocio, siempre alineado con los objetivos de negocio que el software persigue (en nuestro caso, aumentar las ventas). Lo anterior implica, necesariamente, que el software tendrá defectos y errores (más conocidos como bugs). Lo importante es que estos errores no afecten de manera significativa ese 80% de valor. Dado esto, se hace necesaria una categorización de errores y defectos, determinando su severidad en base al impacto que tienen en la propuesta de valor del software. Con esto, es posible establecer una métrica de calidad en torno a los errores y defectos que supere la subjetividad que se mencionaba anteriormente.

‍

La importancia de los usuarios finales

Si el objetivo del producto software es aumentar las ventas, ¿quiénes son los más indicados para probar las funcionalidades del mismo en primeras instancias? Correcto, los vendedores. No son los gerentes, ni los directores, ni las secretarias, y mucho menos los practicantes, los encargados de realizar pruebas. Dado que el software está enfocado en ayudar a los vendedores a aumentar sus ventas, son ellos y sólo ellos los indicados para evaluar su funcionamiento. Entonces, ¿qué debiese hacer el gerente de la empresa ACME?. Debiese asegurarse que los vendedores usen y prueben el software, al tiempo de asegurarse de que reporten todos y cada uno de los defectos y errores que encuentren. Además, medir cuánto tiempo necesita un usuario para dominar sus funciones y usarlo con fluidez, midiendo la intuitividad del mismo. Para ello, el uso del software debe ser integrado de manera gradual al conjunto de usuarios, partiendo por un grupo pequeño (los early adopters) y agregando otros nuevos de manera progresiva a medida que el software aumenta su grado de madurez. También, es necesario exigirle a la empresa desarrolladora la medición de la usabilidad de la interfaz de usuario, con tal de determinar las virtudes y falencias de la misma, ejecutando las acciones correctivas necesarias.

¿Es necesario ponerle un límite al reporte de los errores?. Para nada. Si reportan todos los defectos y errores que detectan, tanto el equipo de desarrollo como la gerencia tendrán un mayor conocimiento sobre el estado del software. Es importante destacar la necesaria adaptación de los usuarios finales (en nuestro caso, los vendedores) a la categorización de errores definida previamente. Si algo no cabe dentro de alguna de estas categorías, el defecto quizás no es tal y el reporte del vendedor pasa a ser una solicitud de mejora o de una nueva función. Para efectos prácticos nos referiremos a todos estos reportes como incidencias.

En este punto es importante que el gerente de la empresa ACME exija una herramienta de gestión de tickets para gestionar el reporte de estas incidencias. Usar Whatsapp o el correo electrónico para estos fines desencadenará, más temprano que tarde, en un infierno de duplicaciones y pérdida de información.

‍

¿Y la calidad interna?

La empresa desarrolladora debería, por sí sola, entregar un informe periódico con las métricas de calidad interna del software en desarrollo. Esto, no con el objetivo de evaluar si las métricas son buenas o malas, si no para verificar en el tiempo si es que la calidad interna del software mejora, se mantiene o empeora. Claramente, si los indicadores de calidad interna empeoran, es necesario exigir explicaciones a la empresa desarrolladora y hacerla cumplir con el deber (moral y/o contractual) de entregar un software de calidad.

Sin calidad interna no puede existir calidad externa. La calidad externa descansa sobre lo que ocurre tras bambalinas, en el código fuente. No hay dobles lecturas sobre esto. En palabras Henrik Kniberg, “es difícil construir algo sobre cimientos podridos”.

‍

Conclusiones

A pesar de todas las dificultades, medir la calidad de un software es posible. De hecho, es necesario. Un software nunca deja de crecer o de modificarse en pos de mejorar su funcionamiento, por lo que es necesario contar con métricas que permitan hacer un seguimiento a su evolución en el tiempo.

Considerar tanto la calidad externa como interna basta para cubrir los diferentes aspectos de un software. Lo más importante es que no se necesitan grandes conocimientos en Tecnologías de la Información o en desarrollo de software para evaluar el estado de calidad de una aplicación. Con lo aquí planteado, es posible identificar dónde poner los énfasis que la calidad de un software requiere.