Calidad del software es mucho más que el testing

A lo largo de estos años, el concepto de calidad del software y lo que engloba ese término ha ido evolucionando bastante.
Actualmente, bajo calidad del software englobamos la calidad del proceso (el conjunto de actividades que utilizamos para desarrollar el software), donde entrarían temas como metodologías ágiles, CMMI etc.; calidad del producto (calidad del propio software que desarrollamos) y calidad de las personas (motivación del equipo, si es multifuncional etc.).
Si quieres profundizar más en estas diferencias, recuerda el post No es lo mismo calidad del PRODUCTO software, que calidad del PROCESO software, que calidad del EQUIPO.
En un primer momento, e imitando la perspectiva industrial, nos centramos en optimizar, medir y mejorar solamente la calidad del proceso de desarrollo, con la esperanza de que como ocurre con las cosas físicas, un mejor proceso equivaldría a un mejor producto.
Pero fallamos. Nos dimos cuenta de que un buen proceso influye, pero no asegura la calidad del producto que realicemos.
Por ello, aunque siempre estuvo ahí, sin tener la importancia que se merecía en todos los sitios, ahora empezamos a fijarnos más en la calidad del producto.

Pero, ¿qué es calidad del producto software?

¡Hombre, yo lo sé, nosotros medimos la calidad del producto software que desarrollamos! Tenemos un departamento de testing.
Y tienes parte de razón. El testing es imprescindible para conseguir una buena calidad del software.
Pero el testing normalmente solo mide software en ejecución.
El testing, (sobre todo el funcional que se nos suele venir a la cabeza al pensar en estos temas) suele ser es una actividad de caja negra, es decir, proporcionando unas ciertas entradas al software, observamos que las salidas que nos devuelva ese software sean las esperadas.
Pero que nuestro software funcione no implica necesariamente que esté bien construido.
Además, en muchas ocasiones, cuando hablamos de testing solo miramos pruebas funcionales.
Y así se dan situaciones como:
¡Pero si tengo QA! ¿Por qué me encuentro que…?:
– Esto no es lo que quería el cliente.
– Hay muchísimos defectos en producción.
– ¿Si este fallo lo solucionamos hace 2 semanas por qué volvemos a verlo ahora?
– ¿Por qué tardáis tanto añadir una funcionalidad de nada?
…
Para bien o mal de muchos, el software no es una cosa física. Y engloba muchísimas perspectivas.
Si hablamos de calidad del producto software, la norma por excelencia es la ISO 25000, que ha ido evolucionando a lo largo de muchos años.
Para que te hagas una idea, esta norma define que calidad del producto software es:
– Factores externos que afectan al software (p.e las cómo afecta al software las máquinas, servidores en los que se ejecuta).
– Cómo percibe el software el usuario/cliente.
– Cómo está creado el software internamente.
Dentro de este último punto, hay 8 características de calidad a medir dentro del propio software, como por ejemplo la Mantenibilidad (capacidad de un producto software para ser modificado), la Eficiencia (capacidad del software para hacer buen uso de los recursos que manipula), Portabilidad (facilidad con que un sistema software puede ser migrado entre diferentes plataformas hardware o software), Fiabilidad (grado en el que un programa se espera que realice su función con una precisión requerida), etc.
Por ello existen otro tipo de pruebas o mediciones llamadas de caja blanca, que sí observan cómo está construido el software, donde miramos deficiencias de esas características de calidad del software.
Lo que hacemos es analizar el código fuente en busca de indicadores, métricas que proporcionen información acerca de la calidad de ese código.
Cada aplicación software tiene diferentes requisitos de calidad, en base a su propósito y el contexto en el que se usa. En función de estos requisitos nos interesará medir y mejorar unas características u otras.
Por ejemplo, para un software que continuamente interactúa con el cliente, es indispensable la Usabilidad. En cambio, una aplicación web también necesita Seguridad, mientras que para una aplicación muy crítica son indispensables la correctitud funcional y la fiabilidad. Y en la mayor parte de los casos tendremos que cambiar el software, evolucionarlo y adaptarlo, por lo que nos interesará la Mantenibilidad.
¿Cómo puede alguien solucionar todos estos problemas, solo mirando entradas y salidas del software?
Es imposible. El testing ese que se nos viene a la mente, es solo una pieza de la calidad del software, pero no la única.
Por ello en cuanto a calidad del producto software es importante estudiar los factores de riesgo de nuestro negocio, qué debe cumplir nuestra aplicación y definir un plan de pruebas (tanto caja blanca, como caja negra) que se adapte a nuestras necesidades.
Y no nos olvidemos de que calidad del software es calidad de proceso + calidad de producto + calidad de las personas.

Entonces, ¿quién es el responsable de QA en una empresa software?

Creo que la visión del rol de QA (el tester funcional de toda la vida) que tenemos se queda corta, para todo lo que la calidad del producto software y la calidad del software en general conlleva.
– La calidad tiene que estar presente desde siempre, desde que empezamos a pensar el software.
– La calidad tiene que estar incluso en la persona que desarrolla software.
– Promovemos calidad del software cuando conseguimos definir y aplicar una estrategia de versionado del software.
– Cuando en una retrospectiva de Scrum analizamos los fallos de este sprint y plateamos acciones para mejorar en el siguiente.
– Cuando alguien automatiza procesos repetitivos, para dar más facilidades a los desarrolladores a la hora de realizar su trabajo.
– También cuando refactorizamos una clase para mejorar su mantenibilidad estamos hablando de mejor calidad del software.
– Cuando hacemos que los clientes se involucren con nosotros para crear mejor software.
– Cuando conseguimos que nuestro equipo esté motivado.
– Cuando probamos que la aplicación cumple con las funcionalidades que se esperaban.
– Cuando detectamos fallos.
– Cuando no olvidamos que la creación del software es un proceso intelectual, creativo, no mecánico.
Todo eso es calidad del software. Y podría continuar esa lista.
Así que por favor, no te quedes en que calidad del software es solo testing. Ni tampoco la entiendas como querer industrializar el software. El software no funciona así.
 

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024