Pages Menu
Categories Menu

Posted by on Dic 12, 2014 in General | 10 comments

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

 

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

10 Comments

  1. Que buen post!! De esos que llenan la lista de propósitos para el año nuevo. 🙂

    • ¡Muchas gracias! 🙂 Esperemos entonces que 2015 sea el año para dar el paso hacia otros ámbitos de la calidad del software 😉

    • 😉

  2. Buenisimo post, como todos los que acostumbras a hacer Ana M.
    Sigue así 🙂

    • ¡Gracias!

  3. Muy buen Post… El responsable de QA en un equipo de trabajo Quien es, como debo elegirlo o que capacidades debe tener, quien debe ser esa persona, el mismo programador, el jefe de proyecto, u otro externo?. En el ciclo de vida tradicional de SW, se menciona al Testing como el proceso final de este ciclo, debiendo este proceso estar en todas las actividades del ciclo de vida del desarrollo de SW.

    • Gracias!

      Esto es un tema para debatir, pero creo que aunque la calidad del software debe estar en toda la gente que interviene durante el ciclo de vida del software, en todo el equipo, si que veo necesaria la figura del QA.

      Me da igual quien sea, solo que sea alguien que esté mucho más especializado en estos temas.

      Los desarrolladores deben hacer sus pruebas, programar aplicando buenas prácticas etc, pero veo necesario que exista alguien, o un grupo de personas más especializadas, que por ejemplo tengan ese pensamiento de «tester» para detectar fallos más complicados, gente experta en buenas prácticas a la que consultar cuando no se sabe cómo hacer algo de la mejor manera etc.

  4. Me parece muy bien la lista que hiciste, eso es Calidad, el problema que muchos puntos no se cumplen en varios proyectos. Además en esa lista hay muchas tareas que se debe encargar el Líder o el PM, y no el QA, así que creo que la Calidad de Software (1+2+3) no depende solo del QA sino de toda la empresa.
    RRHH hace calidad contratando a los más capacitados y NO a los que ofrecen menos sueldo.
    Los desarrolladores hacen calidad cuando se realiza aunque sea un caso feliz antes de pasarlo a testing, cuando tienen las versiones ordenadas y saben en qué versión se reproduce un error y en cual está arreglado
    El analista hace calidad cuando el documento que redacta es claro y conciso y el tester puede diseñar sus casos de prueba casi sin tener que consultarle al analista sobre lo que quiso escribir
    El líder hace calidad cuando tiene una respuesta rápida y clara a las preguntas y dudas que realizan los analistas, testers y desarrolladores
    Saludos!!!

    • ¡Totalmente de acuerdo! 🙂

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This