El ISTQB la calidad como “el grado en que un componente o sistema satisface las necesidades declaradas e implícitas de sus diversos interesados”. Entonces, con base en los enfoques de Cunningham y ISTQB, cualquier deuda técnica es, de hecho, una falta de calidad del software.
Hay muchas formas en las que la calidad del software se ve (in)advertidamente comprometida
Es bien sabido que la amplia adopción y la presencia generalizada del software como parte de nuestra vida cotidiana (pero también con frecuencia en aspectos extremadamente críticos) junto con el rápido ritmo de lanzamiento del software (principalmente derivado de las decisiones de lanzamiento al mercado de nuevas funciones, pero también debido a problemas de seguridad y reparación de defectos), ha llevado a pensar en la “Calidad” como un proceso crítico dentro del Ciclo de Vida de Desarrollo de Software (SDLC). No obstante, esta “Calidad” crítica a menudo se ve comprometida en nombre de la prisa por impulsar el software “a la brava” por:
- No dar suficiente tiempo para definir la definición de calidad de un producto, es decir, formalizar su especificación de cumplimiento,
- No probar el producto lo suficiente, es decir, no hay suficiente tiempo para las pruebas, no hay suficiente cobertura de prueba (más sobre esto más adelante), o cuando el equipo es demasiado pequeño, sin experiencia o sin el conjunto de habilidades adecuado para realizar un trabajo adecuado.
- Descuidar los procesos de calidad generales (o estandarizados por la industria), las mejores prácticas y los entregables relacionados con la calidad.
Estas decisiones deliberadas son erróneas por lo menos de 4 maneras:
- Evitan que los equipos se den cuenta de los problemas de incumplimiento de las funciones que se lanzan, lo que con el tiempo se convierte en una nueva deuda técnica. (Vea un ejemplo en la migración del sistema judicial del condado de Rutherford )
- Asumen que la funcionalidad actual de un producto seguirá funcionando en las nuevas versiones, lo que podría pasar por alto los defectos, lo que acumula Deuda técnica de los requisitos nuevos y anteriores (consulte el análisis de fallas en el lanzamiento de Ariane 5 Rocket )
- Dependiendo de la situación, utiliza por debajo o por encima de la capacidad de los ingenieros de control de calidad, lo que desperdicia recursos o aumenta los costos, respectivamente, y en general estresa al equipo (consulte “¿ Fracasando en las pruebas de software basadas en requisitos? “).
- Reducen la certeza de una implementación al descartar los riesgos de facto y, por lo tanto, reducen la confianza en el lanzamiento en detrimento de la estabilidad del producto y la reputación de la empresa (ver ” Qué ha cambiado realmente tres años después de la violación de Equifax“).
Este es un juego de números
Una forma de saber qué tan bien lo está haciendo un equipo para garantizar la calidad de un producto de software (aparte de las críticase de los clientes reales) es introduciendo métricas de calidad. Tanto la industria como la academia están mejorando continuamente la definición de métricas de calidad del software que dan cuenta de las pruebas que se realizan (o la falta de ellas) como una instantánea del estado actual del software pero (si se analizan a través de la evolución del proyecto) también pueden dar información sobre tendencias de calidad y ayuda a identificar y explicar en parte los puntos débiles. Esto es cierto para cualquier tipo de SDLC.
Sin embargo, la industria del software no se ha puesto realmente de acuerdo sobre un conjunto estandarizado y completo de métricas de calidad y algunos proyectos incluso han desarrollado valores personalizados derivados de fórmulas complejas integradas en paneles digitales fáciles de leer con indicadores compuestos para generar informes casi en tiempo real de tales mediciones.
Aparte del papel que estas mediciones continuas están jugando en nuevos enfoques como la ingeniería de confiabilidad del sitio o SRE por sis siglas en inglés (especialmente con respecto a la ejecución de pruebas automatizadas), a veces es realmente difícil explicar las métricas de calidad en sí mismas a personas no técnicas, y mucho más difícil comunicar estos números personalizados y demasiado complicados mencionados anteriormente (incluso con gráficos bonitos y animados).
En el interés de simplificar las cosas, cada proyecto debe introducir al menos las siguientes 3 métricas complementarias:
- Una métrica de cobertura de pruebas de calidad que refleja el porcentaje de requisitos cubiertos por al menos una prueba (uno pensaría que esta métrica debería estar cerca del 100 % en proyectos de software, pero se sorprendería)
- Una medida de pruebas de calidad ejecutadas (porcentaje de pruebas planificadas frente a pruebas realmente realizadas)
- Tasa de pruebas pasadas (porcentaje de pruebas que cumplieron con los criterios de éxito esperados vs las pruebas ejecutadas)
Estas 3 métricas combinadas deberían brindarle al equipo una imagen suficientemente amplia del trabajo de calidad. Hay muchas más métricas relacionadas con la calidad, pero tenga en cuenta que, en aras de la brevedad y la simplicidad, estamos omitiendo deliberadamente las de automatización de pruebas y las métricas relacionadas con defectos.
Introduciendo el concepto de Deuda de Calidad
Para los efectos de esta serie de publicaciones, la desviación de cualquiera de las 3 métricas del 100% se etiquetará como “Deuda de calidad”. Si bien existen otras definiciones de Deuda de Calidad (por ejemplo, la de Hammerslag, D. 2013), estas se centran principalmente en los defectos en lugar de la calidad del software en su conjunto. Cabe señalar que la Deuda de Calidad debe documentarse al final de cada Ciclo de Calidad.
Según esta definición simple pero fundamentada, la deuda de calidad se puede amaterializar en 4 elementos o artefactos tangibles:
- Un registro de defectos: como era de esperar, una prueba fallida puede interpretarse como el “desacuerdo entre los requisitos y la funcionalidad desplegada” (o como un incumplimiento de los criterios predefinidos) y puede traducirse directamente en un defecto que se registra en una bitácora de defectos.
- Nuevos requisitos o elementos en el backlog: incluso cuando se pasa una prueba, esta puede revelar aspectos de la funcionalidad previamente inadvertidos que pueden conducir a nuevos requisitos o criterios de aceptación. Ejemplos de algunos elementos comunes del backlog son aquellos relacionados con la seguridad, la privacidad o la experiencia del usuario (especialmente cuando no se consideran desde las fases de diseño o son ideas posteriores a la implementación del producto).
- Material de prueba aumentado: a menudo, los ingenieros de calidad experimentados identifican conjuntos de escenarios de prueba completamente nuevos, quizás relacionados con una nueva función o con nuevas entradas de datos vinculadas a nuevos estados, condiciones o resultados esperados. Otro ejemplo de software de prueba aumentado es la evolución de los casos de prueba actuales en sus versiones automatizadas o la incorporación de estas pruebas automatizadas en software de integración continua (CI/CD), no solo para ejecuciones nocturnas (es decir, buscando pruebas continuas) sino hasta lograr el monitoreo de aplicaciones “en vivo”.
- Informe de brecha de esfuerzo de calidad: este documento debe contener los resultados de (al menos) las 3 métricas de calidad mencionadas anteriormente que ayudan a los gerentes de desarrollo y a las partes interesadas a tomar decisiones informadas y evaluar mejor el riesgo de una implementación determinada en función de las diferencias entre lo que ingenieros de calidad diseñaron y lo que realmente sucedió durante el ciclo de calidad.
Al pensar en la Deuda Técnica del Software desde la perspectiva de la calidad del software, se revela un camino más claro para su comprensión y medición, y uno puede comprender más ampliamente sus implicaciones en varios aspectos del proyecto. La deuda de calidad pretende ser un proceso más tangible y más fácil de estimar que requisitos “abstractos” o incompletos o definiciones de funciones (ver, por ejemplo, la hipótesis del valor de las funciones).
En la siguiente publicación, abordaremos cómo trabajar con estos cuatro elementos procesables para ayudar a reducir su deuda de calidad.
