Categorización de Defectos de Software: una propuesta

En la dinámica actual y especialmente en ciudades con alto grado de urbanización, nuestras vidas literalmente dependen del software. Los sistemas y las aplicaciones (en sus diferentes presentaciones) forman parte de nuestro día a día y una porción significativa de nuestar labor productiva, social, personal y hasta familiar pasa cotidianamente (como información) a través de ellas.

La certeza del correcto funcionamiento del software es algo que generalmente damos por sentado; sin embargo, siendo el éste (todavía) producto de humanos, también está sujeto a errores los cuales pueden tener diferentes fuentes y muy diversos efectos, desde cálculos erróneos, funcionalidad inhabilitada, imposibilidad de guardar cambios, hasta fuga de información. Dependiendo del contexto, tales efectos pueden pasar desapercibidos o poner en riesgo la vida de las personas.

Por esta razón la gestión de defectos (estén atentos sobre una próxima publicación sobre este tema) es un proceso fundamental en el desarrollo de software. Una parte de dicha gestión consta de analizar el orígen y causas del defecto (pronto viene una publicación sobre RCA) para entender cómo se gestó, qué impacto tuvo, cuál fue el proceso para su solución y cómo se pueden reducir errores similares en el futuro.

En mi experiencia con proyectos de software de diversas industrias, arquitecturas, tecnologías, plataformas y magnitudes, he compilado y desarrollado una clasificación de defectos relativos a su orígen que propicia las siguientes ventajas:

  • Ecualiza los defectos: Agrupa los defectos por causas, independientemente de sus consecuencias o la magnitud de su impacto.
  • Apoya en su priorización: permite realizar una comparativa de volúmenes entre categorías.
  • Aprovecha lecciones aprendidas: sirve como apoyo en el análisis de la ejecusión de medidas generales tanto correctivas como preventivas, por ejemplo relacionadas con las mejores prácticas asociadas a la categoría o que hayan sido aplicadas con anterioridad en defectos de la misma cateogoría.
  • Promueve procesos de mejora: sirve como base en la generación o derivación medidas correctivas o preventivas adicionales sobre una base probada y común.
  • Democratiza su gestión: al considerar que los defectos se producen por la interacción de los miembros de un equipo y no solo de un rol particular.

Las categorías propuestas obedecen a tres premisas fundamentales:

  • Atender a las causas del defecto y no a las consecuencias (causalidad)
  • Generar el menor traslape posible entre las categorías (segregación)
  • Procurar el agrupamiento de todos los defectos (universalidad)

Como veremos en la discusión posterior, en la práctica pueden ocurrir casos en los que sea difícil realizar clasificación del defecto, es principalmente por esta razón que la lista propuesta no pretende ser exahustiva ni definitiva, sino servir como guía para que cada equipo desarrolle su propio esquema de modo que se ajuste al contexto y las condiciones de sus proyectos.

Categorías para la clasificación defectos

Defectos causados por datos: este tipo de defectos tiene su origen en la fuente donde se almacena la información para su extracción y posterior procesamiento y/o despliegue. Por ejemplo: datos almacenados en formato incorrecto o con valores inapropiados, recursos (imágenes, documentos, tipografías) erroneos o no disponibles, etc.

Defectos causados por lógica de programación: este tipo de defectos causan problemas en la funcionaliad del software y son relativos a una mala implementación del algoritmo, o el proceso que puede estar relacionada con la falta de análisis de los datos de entrada, una intepretación incorrecta del requerimiento (procesamiento de datos y la salida del proceso), errores en la codificación (inicialización de variables, mal posicionamiento de elementos de inicio o fin de bloques de código, etc).

Defectos causados por procesos del SDLC: este tipo de defectos son causados por la falta de seguimiento (o la inexistente definición) de procesos relacionados con la generación y despliegue del código del software; por ejemplo, el seguimiento de estándares de codificación, el despliegue de elementos relacionados en conjunto (código adicional, archivos de configuración, recursos asociados o cambios en el esquema de bases de datos), ejecusión de pruebas (unitarias, de humo o de regresión), etc.

Defectos causados por Requerimientos incompletos: este tipo de defectos están relacionados con ambiguedades u omisiones en los requerimientos que dejan a la interpretación del lector aspectos importantes sobre la implementación y funcionalidad deseada. Por ejemplo en procesos ágiles es muy común que no se cumpla con el “Definition of Done” para las historias de usuario, y en equipos no muy maduros tiende a causar conflictos entre la intepretación de quien va a desarrollar la funcionalidad respecto a quien la va a probar. Una manera de identificar estos defectos es cuando en las discusiones entre los desarrolladores y los ingenieros de calidad aparecen fraces como: “es que yo pensé”, “lo que yo había entendido es”, o “como no decía, asumí”.

Defectos causados por las herramientas o el ambiente del SDLC: hay ocasiones en los que un defecto surge aún cuando tanto el código como los datos son correctos y se siguieron los procesos de manera correcta. Muchos de ellos son causados por inconsistencias en los ambientes en los que se despliega el código, configuraciónes erróneas, conflicto en versiones de software requerido, uso de herramientas no estandarizadas para el desarrollo o la promoción del código, etc.

Defectos Inválidos: esta categoría no obedece a una causa sino a la necesidad de agrupar los “defectos defectuosos”, es decir, aquellos defectos que luego de una revisión terminaron siendo funcionalidad esperada o se descarta su atención por no obedecer a una especificación o inclusive por ser trivial en el contexto. En muchos casos estos defectos son eliminados de la bitácora; sin embargo, es importante mantenerlos como evidencia tanto del esfuerzo invertido por quien lo registró como de que los ingenieros de pruebas también cometen errores.

Defectos Removidos: esta categoría no obedece a una causa sino a la necesidad de agrupar aquellos defectos que por cualquier causa no sean atendidos por el equipo que los generó, sino que son extraídos para su atención por otro equipo. En muchas ocasiones los equipos pierden visibilidad del destino de este tipo de defectos por lo que es importante mantener evidencia de su existencia y (en la mayoría de los casos) procurar su seguimiento para la correcta actualización de su estado (por ejemplo si está todavía abierto, en progreso o cerrado)

En efecto, se pudiera pensar (especialmente si comulga con la frase “todo se reduce a las matemáticas”), que las categorías pudieran reducirse también solo a “procesos, procesos, procesos”. En la práctica, el desarrollo de software es mucho más complejo. Esta visión reduccionista toma en cuenta que establecimiento y consecuente seguimiento de procesos previene fallas subsecuentes, de modo que si un defecto se presenta es por la falta de seguimiento o definición de un proceso.

Existen diversos modelos de desarrollo de softare que funcionan bajo esa premisa pero requiere que el equipo y los procesos sean maduros, y por lo tanto el número de defectos inyectados debría ser menor de manera proporcinal. Sin embargo, en el mundo ágil del desarrollo de software, simplemente no es el caso.

El contexto diverso de cada proyecto de software hace que la clasificación de un defecto dentro de una de las categorías propuestas pueda ser relativamente sencilla o muy compleja. Un ejemplo en el que se observa la complejidad de la clasificación es el siguiente:

Imagine un escenario donde una página web tiene un error en un texto legal donde algunas palabras cuentan con símbolos no alfanuméricos. Al ser un texto relativamente estático, de primera instancia se puede pensar que es un defecto de contenido relacionado con los datos pero al verificar el almacenamiento no se observan los símbolos mencionados.

Una investigación más profunda revela que el texto fue extraido desde la herramienta de gestión de requerimientos e insertada en el archivo de almacenamiento mediante un proceso copy-paste; sin embargo, el programa de edición de textos utilizado para actualizar el archivo de almacenamiento del texto resultó incompatible con el formato UTF, por lo que aparentemente el texto visualmente es correcto pero su representación binaria en el archivo causa la aparición de símbolos cuando se extrae el texto para su inserción en la página web.

Si existe una política definida para el equipo sobre el uso de herramientas para los procesos de extracción de texto, entonces es un defecto causado por no seguir los procesos del SDLC; de lo contrario es un defecto causado por las herramientas del SDLC y como medida de mitigacíón se establecería la política mencionada.

La dinámica del universo del desarrollo de software es en realidad más caótica e inexpugnable de lo que parece, por lo que para mí cualquier elemento de guía o apoyo puede hacer la diferencia entre encallar o llegar a buen pruerto.

Desarrollate, desarrollando!

Deja tus comentarios en Linkedin o en Twitter.