2. Gestión de Producto

Duración: 390 minutos

Palabras Clave

En la siguiente tabla se presentan las palabras clave del capítulo. En este documento, se identifican dos tipos de palabras clave: PROCESO (que identifican palabras clave del proceso de prueba general) y ESPDOM (que identifican palabras clave específicas de dominio).

Tipo Palabra Clave	Español	Inglés
PROCESO	anomalía	anomaly
PROCESO	defecto	defect
PROCESO	informe de defecto	defect report
PROCESO	flujo de trabajo de defectos	defect workflow
PROCESO	fallo	failure
PROCESO	métrica	metric
ESPDOM	póker de planificación	planning poker
PROCESO	estimación de la prueba	test estimation
PROCESO	objetivo de prueba	test objective
PROCESO	avance de la prueba	test progress
ESPDOM	estimación de tres puntos	three-point estimation
ESPDOM	Delphi de banda ancha	Wideband Delphi

Objetivos de Aprendizaje para «Capítulo 2»

2.1 Métrica de Prueba

• TM-2.1.1 (K2): Dar ejemplos de métricas para alcanzar los objetivos de prueba.
• TM-2.1.2 (K2): Explicar cómo controlar el avance de la prueba utilizando métricas de prueba.
• TM-2.1.3 (K4): Analizar los resultados de prueba para crear informes de prueba que empoderen a los implicados en la toma de decisiones.

2.2 Estimación de la Prueba

• TM-2.2.1 (K2): Explicar los factores que se necesitan tener en cuenta en la estimación de la prueba.
• TM-2.2.2 (K2): Dar ejemplos de factores que pueden influir en la estimación de la prueba.
• TM-2.2.3 (K4): Seleccionar una técnica o enfoque de estimación de la prueba apropiado para un contexto determinado.

2.3 Gestión de Defectos

• TM-2.3.1 (K3): Implementar un proceso de gestión de defectos, incluyendo el flujo de trabajo de defectos, que se pueda utilizar para monitorizar y controlar los defectos.
• TM-2.3.2 (K2): Explicar el proceso y los participantes necesarios para una gestión de defectos eficaz.
• TM-2.3.3 (K2): Explicar los detalles de la gestión de defectos en el desarrollo ágil de software.
• TM-2.3.4 (K2): Explicar los retos de la gestión de defectos en el desarrollo de software híbrido.
• TM-2.3.5 (K3): Utilizar los datos y la información de clasificación que se deben recopilar durante la gestión de defectos.
• TM-2.3.6 (K2): Explicar cómo se pueden utilizar las estadísticas del informe de defecto para idear la mejora del proceso.

2.1 Métricas de Prueba

Introducción – ¿Por qué Disponer de Métricas de Prueba?

Hay un dicho en gestión que dice: “Lo que se puede medir, se hace”. Del mismo modo, lo que no se mide no es probable que se haga porque es fácil de ignorar. Por lo tanto, es importante establecer un conjunto adecuado de métricas para cualquier empresa, incluidas las pruebas.

Los objetivos de prueba son la respuesta a por qué probamos (véase la sección 1.4, La estrategia de prueba del proyecto). Para determinar si se han cumplido los objetivos de prueba, hay que definir una forma de medirlos. Las métricas de prueba son los indicadores que nos ayudan a responder a esta pregunta.

Las métricas de prueba pueden clasificarse de la siguiente manera:

• Las métricas de proyecto miden el avance respecto a los criterios de salida del proyecto en curso, como el porcentaje de pruebas ejecutadas, pasadas y falladas.
• Las métricas de producto miden atributos del producto como el grado en que el producto cumple las expectativas de calidad de los usuarios previstos.
• Las métricas de proceso miden la capacidad del proceso de prueba y la efectividad de la prueba. Las métricas del proceso se utilizan, por tanto, para informar sobre la efectividad y la eficiencia del proceso.

Para obtener más información sobre la gestión de métricas de productos y de procesos, se recomienda consultar el programa de estudio de nivel experto en gestión de pruebas. Asimismo, para profundizar en el uso de métricas de procesos, se puede consultar el programa de estudio de nivel experto orientado a la mejora del proceso de prueba.

En las siguientes secciones se tratarán las métricas para la planificación de la prueba, la monitorización de la prueba, el control de la prueba y la compleción de la prueba. Estas son las cuatro principales actividades de gestión relacionadas con las métricas.

Métricas para las Actividades de Gestión de la Prueba

La gestión de la prueba debe ser capaz de definir un conjunto de métricas para la monitorización de la prueba, el control de la prueba y la compleción de la prueba como parte de las actividades de planificación de la prueba. Cada métrica debe definirse, medirse, monitorizarse e informarse.

Durante la planificación de la prueba, se definen las métricas de prueba apropiadas que coinciden con los objetivos de prueba de la estrategia de prueba del proyecto.

Las métricas utilizadas durante la monitorización de la prueba y el control de la prueba pueden ser diferentes de las utilizadas en la compleción de la prueba. Durante la monitorización de la prueba y el control de la prueba, las métricas se refieren al avance de las actividades de prueba. En la compleción de la prueba, deben alcanzarse los objetivos de la prueba. Podrían combinarse una o varias métricas para medir los criterios de salida de la prueba asignados a determinados objetivos de prueba.

La siguiente tabla ofrece ejemplos de métricas (existen muchas más) utilizadas en las actividades de gestión de la prueba:

Métrica (planificada/monitorizada para hitos definidos)	Monitorización de la prueba y control de prueba	Compleción de la prueba
Cobertura de requisitos	X	X
Cobertura del riesgo de producto	X	X
Cobertura de código	X
Estimación real frente a la prevista (en horas) para las actividades de prueba	X
Porcentaje de casos de prueba ejecutados por estado (por ejemplo, fallidos, bloqueados) frente a los casos de prueba planificados	X	X
Número acumulado de defectos resueltos frente al número acumulado de defectos	X
Casos de prueba automatizados reales frente a casos de prueba automatizados planificados		X
Coste real frente al coste planificado de la prueba	X

Tabla 2. Ejemplos de métricas utilizadas en las actividades de gestión de la prueba.

Las métricas con una «X» en monitorización de la prueba y control de la prueba se utilizan principalmente para medir el avance y se informan en los informes de progreso de la prueba. Las métricas con una «X» en compleción de la prueba se utilizan principalmente para medir la consecución de los objetivos de la prueba y se informan en el informe de compleción de la prueba. Las métricas con una «X» en ambas columnas pueden utilizarse para cualquiera de las dos cosas.

También existen métricas para monitorizar la efectividad de la prueba, por ejemplo, el Porcentaje de Detección de Defectos (PDD). El PDD se aborda formalmente en el programa de estudio de nivel experto, en el módulo de mejora del proceso de prueba, concretamente en la sección de implementación de la mejora del proceso de prueba.

Monitorización, Control y Compleción

Las métricas de prueba son indicadores que muestran hasta qué punto ha avanzado la prueba y si se han alcanzado los criterios de salida o las tareas de prueba relacionadas.

La monitorización de la prueba es la actividad de recopilación de datos relativos a la prueba y a la evaluación asociada. Se utiliza para evaluar el avance de la prueba y comprobar el cumplimiento de los criterios de salida o las actividades de prueba asociadas (véase el apartado 1.1.2, Actividades de Monitorización y Control de la Prueba). Los criterios de salida se obtienen a partir de los objetivos de prueba.

El control de la prueba utiliza la información de la monitorización de la prueba para proporcionar directrices y acciones correctivas con el fin de lograr una prueba eficaz y eficiente. Entre los ejemplos de directivas de control de pruebas se incluyen el cambio de prioridad de las pruebas cuando un riesgo identificado se convierte en un problema, la reevaluación de si un elemento de prueba cumple los criterios de entrada o los criterios de salida debido a la repetición de pruebas, el ajuste del calendario de pruebas para tener en cuenta un retraso en la entrega del entorno de prueba y la adición de nuevos recursos cuando y donde sea necesario.

La compleción de la prueba recopila datos de las actividades de prueba completadas para consolidar las lecciones aprendidas, el producto de prueba y otra información relevante. La compleción de la prueba se produce en hitos del proyecto como la compleción de un nivel de prueba, la compleción de una iteración, la compleción (o cancelación) de un proyecto de prueba, la entrega de un producto o la compleción de una entrega de mantenimiento.

Entre las métricas de prueba habituales que se utilizan en las actividades de gestión de pruebas se incluyen las métricas de avance del proyecto y las métricas que muestran el avance con respecto al calendario y el presupuesto previstos, la calidad actual del elemento de prueba y la efectividad de la prueba con respecto a los objetivos de la prueba o los objetivos de la iteración.

Suministro de Información de Prueba

La gestión de la prueba debe comprender cómo interpretar y utilizar las métricas para comprender e informar del estado de la prueba. Para los niveles de prueba superiores, como la prueba de sistema, la prueba de integración de sistema, la prueba de aceptación y la prueba de seguridad, la base de prueba principal suelen ser los productos de trabajo, como las especificaciones de requisitos, los casos de uso, las historias de usuario y los riesgos de producto.

Las métricas de cobertura estructural son más aplicables a los niveles inferiores de las pruebas, como la prueba de componentes y la prueba de integración de componentes. Aunque la gestión de la prueba puede utilizar métricas de cobertura de código para medir el grado en que sus pruebas ejercitan la estructura del sistema sometido a prueba, el suministro de información sobre los resultados de la prueba de nivel superior debe adaptarse al contexto y a las necesidades específicas del proyecto.

Por ejemplo, en entornos que cambian con frecuencia, la métrica de cobertura de código puede ser útil para monitorizar el impacto de los cambios de código en el juego de pruebas e identificar posibles vacíos o riesgos. Además, la gestión de la prueba debe entender que, incluso si las pruebas de componentes y las pruebas de integración de componentes logran el de su cobertura estructural, los defectos y los riesgos de calidad deben abordarse en niveles de prueba superiores.

El objetivo de informar métricas es proporcionar una comprensión inmediata de la información para fines de gestión. Las métricas pueden informarse como una instantánea de una métrica en un momento dado o como la evolución de una métrica a lo largo del tiempo para evaluar tendencias.

Los riesgos de producto, los defectos, el avance de la prueba, la cobertura y el coste y el esfuerzo de prueba relacionados se miden y se comunican de forma específica al final del proyecto. A continuación, se presentan ejemplos de métricas que pueden utilizarse con distintos fines:

• Métricas relacionadas con los riesgos de producto:

• Porcentaje de riesgos de los que todas las pruebas han pasado.
• Porcentaje de riesgos de los que fallaron algunas o todas las pruebas.
• Porcentaje de riesgos que aún no se han probado en su totalidad.
• Estas métricas pueden utilizarse para evaluar la calidad de la base de la prueba y la efectividad de los casos de prueba para cubrir los riesgos del producto.
• Métricas relacionadas con los defectos:

• Número acumulado de defectos resueltos frente al número acumulado de defectos.
• Desglose del número o porcentaje de defectos categorizados por:

• Elementos de prueba o componentes.
• Origen del defecto (por ejemplo, especificación, nueva prestación o regresión).
• Entregas de prueba.
• Nivel de prueba o iteración introducida, detectada y eliminada.
• Prioridad o severidad.
• Causa raíz.
• Estado (por ejemplo, rechazado, duplicado, abierto, cerrado).
• Estas métricas pueden utilizarse para monitorizar el proceso de detección y resolución de defectos, identificar las áreas de alta densidad de defectos o severidad de defectos, y evaluar la efectividad y eficacia de la prueba.
• Métricas relacionadas con el avance de la prueba:

• Estado de ejecución de pruebas: Número total de pruebas planificadas, implementadas, ejecutadas, pasadas, fallidas, bloqueadas y omitidas.
• Esfuerzo de prueba: Número de horas de recursos reales frente a las planificadas dedicadas a probar.
• Métricas relacionadas con la cobertura:

• Cobertura de los requisitos: El porcentaje de requisitos cubiertos por los casos de prueba.
• Cobertura del riesgo de producto: El porcentaje de riesgos de producto identificados que se ven mitigados por los casos de prueba.
• Cobertura de código: El porcentaje de sentencias de código, ramas, rutas o condiciones que son ejecutadas por los casos de prueba.
• Métricas relacionadas con los costes y el esfuerzo de prueba:

• Riesgos residuales de los componentes no probados: El impacto potencial y la probabilidad de defectos en los componentes que no se han probado.
• Coste de la prueba: El coste real frente al previsto de la prueba.

Adicionalmente, resulta útil combinar métricas de diferentes categorías (por ejemplo, una métrica que muestre la correlación entre las tendencias de los defectos abiertos frente a las tendencias de las pruebas ejecutadas, o una métrica que muestre la calidad de la base de prueba basada en el número de defectos encontrados en los requisitos). Cuando la ejecución de pruebas continúa y cada vez se identifican menos defectos, se puede tomar la decisión de finalizar las pruebas. Esta decisión debe basarse en el suministro de información de las métricas y en los criterios de salida acordados.

2.2 Estimación de la Prueba

Introducción

Existen buenas prácticas de gestión de proyectos para la estimación en ingeniería de sistemas y software, en relación con todo tipo de recursos (por ejemplo, el coste, las personas o el tiempo). La estimación de la prueba es la aplicación de estas buenas prácticas a la prueba asociada a un proyecto u operación.

Estimación de las Actividades que Implicará la Prueba

La estimación de la prueba es una actividad de gestión de la prueba que estima cuánto tiempo, esfuerzo y coste requerirá completar una tarea. La estimación de la prueba es una de las tareas principales e importantes de la gestión de la prueba.

Las principales características de la estimación en la gestión de la prueba son:

• Esfuerzo: El esfuerzo suele calcularse en horas-persona o puntos-historia necesarios para terminar las tareas de prueba del proyecto. A menudo, el esfuerzo de la prueba y la duración de la prueba (tiempo transcurrido) pueden ser diferentes, por lo que la gestión de la prueba puede necesitar estimar la duración total de la actividad.
• Tiempo: Tiempo necesario para finalizar el proyecto. El tiempo es un recurso crítico en un proyecto. La planificación de la prueba necesita estimar el esfuerzo de la prueba en días naturales y en días laborables. Todo proyecto tiene hitos y un plazo de entrega.
• Coste: El coste es el presupuesto del proyecto. Incluye los gastos de los recursos, las herramientas y la infraestructura de prueba.

La prueba suele ser un subproyecto dentro de un proyecto más extenso, a veces distribuido en varias ubicaciones de prueba (por ejemplo, centros de prueba). Para realizar la estimación de la prueba, el primer paso es identificar los niveles de prueba, las actividades de prueba y las tareas de prueba. A continuación, hay que dividir el proyecto de prueba en sus principales actividades de prueba (por ejemplo, la planificación de la prueba y la ejecución de la prueba) dentro del proceso de prueba.

En los proyectos ágiles, las actividades de prueba suelen estimarse dentro del trabajo de desarrollo, y no como valores separados. El siguiente paso consiste en estimar el esfuerzo de prueba necesario para finalizar las tareas o los productos de trabajo y cuáles son los costes esperados de ello.

Como la prueba es una subactividad de un proyecto, siempre hay algunas restricciones naturales del proyecto que influyen en ella y requieren un compromiso, de modo que no se pueden manipular estos valores de forma arbitraria. Eso se puede encontrar en la gestión de la calidad como el triángulo tiempo-coste-calidad. En la gestión de proyectos, el triángulo tiempo-coste-calidad comprende tres valores que son interdependientes, lo que significa que están estrechamente relacionados y se influyen mutuamente.

Factores que Pueden Influir en el Esfuerzo de Prueba

La estimación del esfuerzo de prueba consiste en predecir la cantidad de trabajo relacionado con las actividades de prueba que se necesitará para cumplir los objetivos de prueba de un determinado proyecto, entrega o iteración. Entre los factores que pueden influir en el esfuerzo de prueba se incluyen las características de:

• Producto:

• La calidad de la base de prueba.
• El tamaño del producto a probar (es decir, el objeto de prueba).
• La complejidad del dominio del producto (por ejemplo, el entorno, la infraestructura y el historial).
• Los requisitos para probar las características de calidad (por ejemplo, seguridad y fiabilidad).
• Estos factores relacionados con el producto pueden influir en la estimación de la prueba porque crean un contexto específico para el sistema a prueba.
• Proceso de Desarrollo:

• La estabilidad y madurez de los procesos de desarrollo de la organización.
• El modelo de desarrollo (por ejemplo, desarrollo ágil de software/iterativo, o modelo híbrido de desarrollo de software) en uso.
• Los factores materiales (por ejemplo, la disponibilidad de automatización de la prueba, herramientas y entornos de prueba).
• Estos factores relacionados con el proceso de desarrollo pueden influir en la estimación de la prueba porque esta está directamente relacionada con el desarrollo.
• Personas:

• La disponibilidad y satisfacción de las personas (por ejemplo, la que proporcionan los días festivos, las vacaciones y otros beneficios previstos).
• Las competencias y la experiencia de las personas involucradas, especialmente en lo que respecta a proyectos y productos similares (por ejemplo, conocimiento del dominio).
• Las personas son los recursos más necesarios, por lo que debe tenerse en cuenta cualquier inestabilidad. Por lo tanto, las personas son un factor de gran importancia en la estimación del esfuerzo de prueba. (Véase también la sección 3.1, El equipo de prueba).
• Resultados de prueba:

• El número y la severidad de los defectos encontrados durante la ejecución de prueba.
• La cantidad de retrabajo necesario.
• Las estadísticas históricas apoyan la estimación de la prueba. Por tanto, conocer estos factores apoyará una estimación con valores más precisos.
• Contexto de la prueba:

• La distribución de las pruebas en varias filiales, la composición y ubicación de los equipos, y la complejidad del proyecto (por ejemplo, múltiples subsistemas).
• El tipo de trabajo (por ejemplo, virtual o in situ).
• Los factores relacionados con el contexto son los que afectan a toda la estimación de la prueba. (Véase también la sección 1.2, El contexto de la prueba).

Selección de Técnicas de Estimación de Prueba

La estimación de la prueba debe abarcar todas las actividades que intervienen en el proceso de prueba. La estimación del coste, el esfuerzo y, sobre todo, la duración de la ejecución de la prueba suele ser lo más importante para la gestión de la prueba porque estos valores repercutirán en el proyecto. Sin embargo, las estimaciones de la ejecución de la prueba tienden a ser difíciles de generar cuando la calidad del software en general es baja o desconocida. Además, es probable que la familiaridad y la experiencia con el producto afecten a la calidad de las estimaciones. Una práctica habitual es estimar el número de casos de prueba derivados de la base de prueba (por ejemplo, los requisitos o las historias de usuario). Las suposiciones realizadas durante la estimación de la prueba deben documentarse siempre como parte de la estimación.

Las técnicas o enfoques de estimación de la prueba pueden clasificarse como basadas en métricas o en expertos. (Para más detalles sobre las técnicas de estimación de la prueba básicas, consulte el programa de estudio de nivel básico correspondiente).

En la mayoría de los casos, la estimación, una vez preparada, debe entregarse a la dirección del proyecto, junto con una justificación. Con frecuencia, algunos parámetros de entrada se modifican (por ejemplo, el alcance de la prueba), lo que suele dar lugar a un ajuste de la estimación. Lo ideal es que la estimación final de la prueba represente el mejor equilibrio posible entre los objetivos de la organización y los del proyecto en los ámbitos de la calidad, el calendario, el presupuesto y las prestaciones.

Es importante tener en cuenta que cualquier estimación se basa en la información disponible en el momento en que se elabora. Al principio de un proyecto, la información puede ser bastante limitada. Además, esta información puede cambiar con el tiempo. Para seguir siendo precisas, las estimaciones deben actualizarse para reflejar la información nueva y cambiante.

La selección de la técnica de estimación depende de varios factores, por ejemplo:

• Error de estimación: Algunas técnicas permiten calcular la desviación estándar, que es una medida de la incertidumbre o variabilidad de la estimación. Por ejemplo, la técnica de estimación de tres puntos utiliza las estimaciones optimista, pesimista y más probable para calcular el valor esperado y la desviación estándar de la estimación (para más detalles, consulte el apartado de estimaciones del programa de estudio de nivel básico).
• Disponibilidad de datos: Algunas técnicas requieren datos históricos de proyectos anteriores o similares que pueden no estar disponibles o no ser fiables. Por ejemplo, la estimación basada en proporciones y la extrapolación se basan en datos históricos para obtener las proporciones o las tendencias del proyecto actual.
• Disponibilidad de expertos: Algunas técnicas requieren la participación de expertos que tengan los conocimientos y la experiencia necesarios para proporcionar estimaciones precisas y realistas. Por ejemplo, el método Delphi y el póker de planificación se basan en las opiniones y juicios de expertos o miembros del equipo.
• Conocimientos en modelado: Algunas técnicas requieren el uso de modelos matemáticos o fórmulas para calcular las estimaciones, lo que puede exigir ciertas competencias y conocimientos en modelado. Por ejemplo, la extrapolación y la estimación de tres puntos utilizan fórmulas para obtener el valor esperado y la desviación estándar de la estimación.
• Restricciones temporales: Algunas técnicas requieren más tiempo y esfuerzo para su realización que otras, lo que puede afectar a la viabilidad y adecuación de la técnica. Por ejemplo, el póker de planificación es fácil de realizar, mientras que la extrapolación puede ser más difícil.

Esto demuestra que los criterios de selección de las técnicas adecuadas de estimación de la prueba dependen en gran medida del contexto de prueba (por ejemplo, el ciclo de vida de desarrollo de software (CVDS), los implicados, los niveles de prueba y los tipos de prueba utilizados en el proyecto). El jefe de prueba debe ser capaz de coordinar y aplicar las técnicas de estimación de la prueba (por ejemplo, con diferentes modelos de ciclo de vida de desarrollo de software (CVDS) en un proyecto sobre diferentes entidades subsidiarias).

Por ejemplo, para seleccionar la técnica de estimación adecuada, determine primero la complejidad del tema:

• Si la complejidad es baja, podrían utilizarse técnicas basadas en métricas.
• Si la complejidad es alta, entonces podrían utilizarse técnicas basadas en expertos.
• Si se utiliza un modelo de desarrollo secuencial, entonces podría utilizarse la técnica de estimación Delphi de banda ancha.
• Si se utiliza un modelo de desarrollo ágil de software, podría emplearse el póker de planificación.

2.3 Gestión de Defectos

Introducción

El programa de estudio de nivel básico describe las actividades que se inician tras observar resultados reales que difieren de los resultados esperados. El programa de estudio se refiere a estas actividades como gestión de defectos. Otros estándares utilizan el término «gestión de incidencias» (norma ISO/IEC/IEEE 29119-3) o «gestión de anomalías» para enfatizar el hecho de que al principio del proceso puede que no sepamos si la discrepancia está causada por un defecto en un producto de trabajo, o se debe a algo más (por ejemplo, un fallo de automatización de la prueba o una mala comprensión de los requisitos por parte del probador).

La gestión de defectos y la herramienta utilizada para gestionarlos son de vital importancia para los probadores y para los demás miembros del equipo que participan en el desarrollo del software. La información de un proceso eficaz de gestión de defectos permite al equipo de prueba y a otros implicados en el proyecto conocer el estado de un proyecto a lo largo de su ciclo de vida de desarrollo de software (CVDS). La gestión de defectos también es crucial para decidir qué defectos se corregirán. Esto asegura que el esfuerzo se invierte en trabajar con los defectos correctos. Recopilar y analizar los datos relacionados con los defectos a lo largo del tiempo puede ayudar a localizar áreas de mejora potencial tanto para las pruebas como para otros procesos dentro del ciclo de vida de desarrollo de software (por ejemplo, una mejor prevención de los defectos mediante la mejora de la arquitectura y el diseño técnico).

Además de comprender el ciclo de vida general de los defectos y cómo se utiliza para supervisar y controlar tanto el desarrollo de software como los procesos de prueba, el jefe de prueba y los probadores (o todo el equipo en el desarrollo ágil de software) también deben estar familiarizados con qué datos es fundamental recopilar. El jefe de prueba debe ser un defensor del uso adecuado tanto del proceso de gestión de defectos como de la herramienta de gestión de defectos seleccionada.

Ciclo de Vida de los Defectos

Cada fase del ciclo de vida de desarrollo de software (CVDS) debe incluir actividades para detectar y eliminar defectos potenciales. Por ejemplo, las técnicas de prueba estática (es decir, revisiones y análisis estático) pueden utilizarse en las especificaciones de diseño, las especificaciones de requisitos y el código antes de entregar esos productos de trabajo a las actividades posteriores. Cuanto antes se detecte y elimine cada defecto, menor será el coste global de la calidad del producto. El coste de la calidad se minimiza cuando cada defecto se elimina dentro de la misma fase en la que se introdujo (es decir, cuando el proceso del software logra una contención de fase perfecta).

Durante la prueba estática buscamos defectos. Durante las pruebas dinámicas, la presencia de un defecto se revela cuando provoca un fallo, lo que se traduce en una discrepancia entre los resultados reales y los resultados esperados de una prueba (es decir, una anomalía). En algunos casos, se produce un resultado de falso negativo cuando el probador no observa la anomalía. Cuando se observa una anomalía, debe realizarse una investigación más profunda. Esta investigación suele comenzar rellenando un informe de defecto de acuerdo con el proceso de prueba y gestión de defectos definido. Una prueba fallida no siempre da lugar a la creación de un informe de defecto. (Por ejemplo, en el desarrollo guiado por pruebas, donde las pruebas de componente, normalmente automatizadas, se utilizan como una forma de especificación de diseño ejecutable). Hasta que el desarrollo del componente esté completo, algunas o todas las pruebas deben fallar inicialmente. Por lo tanto, el resultado de una prueba de este tipo no está necesariamente causado por un defecto y no suele ser objeto de seguimiento a través de un informe de defecto.

Un informe de defectos avanza a lo largo de un flujo de trabajo (denominado comúnmente «flujo de trabajo de defectos») y se mueve a través de una secuencia de estados de defectos. En la mayoría de estos estados, una persona es la propietaria del informe de defecto y la responsable de llevar a cabo una tarea (por ejemplo, análisis, eliminación de defectos o prueba de confirmación). El siguiente diagrama representa un flujo de trabajo de defectos sencillo:

        +————+
        |   ABIERTO  |<————————+
        +————+                         |
          |       |                           |
          |       +——–+                  |
          v                v                  |
  +————-+   +————–+          |
  | EN PROGRESO |   |   RECHAZADO  |          |
  +————-+   +————–+          |
          |                |                  |
          v                v                  |
  +————-+          |                  |
  |   RESUELTO  |———-+                  |
  +————-+          |                  |
          |                v                  |
          |         +————–+          |
          |         |   CERRADO    |          |
          |         +————–+          |
          |                ^                  |
          +—————-+——————+

Un flujo de trabajo simple de defectos puede abarcar los siguientes estados de defectos:

• ABIERTO (puede denominarse NUEVO): El estado inicial cuando se crea el informe de defecto.
• EN PROGRESO: El equipo está trabajando en el análisis del informe de defecto y/o en el arreglo correspondiente.
• RECHAZADO: Un informe de defecto es rechazado por la persona que lo ha procesado (normalmente un desarrollador o un analista). Puede haber muchas razones para el rechazo (por ejemplo, información no válida, prueba incorrecta, informe de defecto duplicado) y esta información se añade al informe de defecto.
• RESUELTO (puede denominarse ARREGLADO, LISTO PARA LA REPETICIÓN DE PRUEBA): Un probador ejecuta una prueba de confirmación siguiendo a menudo los pasos para reproducir el fallo a partir del propio informe de defectos para determinar si la corrección ha resuelto realmente el defecto.
• CERRADO: El informe de defecto ha alcanzado su estado terminal y no se pretende realizar más trabajo. El probador pasa el informe de defecto a este estado después de una prueba de confirmación satisfactoria o para reconocer el rechazo del informe de defecto.

En muchas organizaciones se utiliza un flujo de trabajo simple para los defectos, que se amplía con el uso de otros estados de defecto relevantes para un contexto determinado (por ejemplo, REABIERTO, ACEPTADO, CLARIFICACIÓN o APLAZADO).

El flujo de trabajo de defectos puede variar en las distintas organizaciones en cuanto a los distintos nombres de los estados de defectos, las reglas para las transiciones entre estados de defectos y los roles responsables de las tareas en determinados estados de defectos. A menudo, el flujo de trabajo de defectos es más sencillo en el desarrollo ágil de software que en los modelos de desarrollo secuencial. El flujo de trabajo de defectos debe adaptarse a un contexto determinado. Al diseñar el flujo de trabajo de defectos, es aconsejable respetar una serie de buenas prácticas:

• Si es posible, el flujo de trabajo de defectos debe definirse a nivel de toda la organización para proporcionar una gestión de defectos unificada en todos los proyectos.
• Los defectos duplicados y los falsos positivos deben representarse mediante un estado separado o una combinación del estado RECHAZADO con la elección del motivo del rechazo. Pueden ser útiles en posteriores análisis de defectos con el objetivo de mejorar el proceso de prueba.
• Se recomienda utilizar un único estado terminal (por ejemplo, CERRADO). La transición a este estado suele requerir la elección de un motivo de cierre, útil para la evaluación de proceso y las actividades de mejora del proceso.
• Los nombres de los estados en el flujo de trabajo de defectos deben ser los mismos que los de los estados análogos utilizados para otras entidades (por ejemplo, historias de usuario y tareas de prueba) para simplificar el trabajo con ellos.
• Los estados de defecto consecutivos deben pertenecer a diferentes roles responsables. Si dos o más estados consecutivos pertenecen al mismo rol responsable, debe haber una buena razón (por ejemplo, para medir el tiempo pasado en un estado de defecto).
• Cada estado de defecto, excepto el estado terminal, debe tener más de una transición de salida para permitir al rol responsable una decisión respecto al siguiente paso. Las excepciones a esta regla deben estar justificadas (por ejemplo, para monitorizar el tiempo empleado en una actividad determinada).
• El conjunto de atributos que deben introducirse al realizar una transición de estado debe limitarse a aquellos que aporten un valor sustancial a la gestión de defectos.

Gestión de Defectos Transfuncional

Aunque la organización de prueba y el jefe de prueba suelen ser los propietarios del proceso general de gestión de defectos y de la herramienta de gestión de defectos, un equipo interfuncional suele ser el responsable de gestionar los defectos de un proyecto determinado. Este equipo, a veces denominado comité de gestión de defectos, puede incluir al jefe de prueba, representantes de desarrollo, proveedores, gestión de proyectos, gestión del producto o propietario del producto y otros implicados que tengan un interés en el software sujeto a prueba.

A medida que se descubren las anomalías y se introducen en la herramienta de gestión de defectos, el comité de gestión de defectos debe determinar si cada informe de defectos representa un defecto válido y si debe ser corregido (y por qué parte en caso de que varios equipos de desarrollo participen en la entrega), rechazado o aplazado. Esta decisión requiere que el comité de gestión de defectos tenga en cuenta los beneficios, riesgos y costes asociados a la reparación del defecto. Resulta beneficioso debatir esta consideración en una reunión (a menudo denominada reunión de clasificación). Si se va a arreglar el defecto, el equipo debe establecer la prioridad de arreglar el defecto en relación con otras tareas. El jefe de prueba y el equipo de prueba pueden ser consultados sobre la importancia relativa de un defecto y deben proporcionar la información objetiva disponible.

En proyectos muy grandes, el nombramiento de un jefe de defectos a tiempo completo puede estar justificado por el esfuerzo necesario para preparar y hacer un seguimiento de las decisiones tomadas en las reuniones del comité de gestión de defectos, al menos durante las fases del ciclo de vida de desarrollo de software (CVDS) en las que la prueba es más intensiva. En otras situaciones, varios proyectos grandes pueden compartir un jefe de defectos.

Una herramienta de gestión de defectos no debe utilizarse como sustituto de una buena comunicación, ni un comité de gestión de defectos como sustituto del uso eficaz de una buena herramienta de gestión de defectos. La comunicación, un soporte adecuado de la herramienta, un flujo de trabajo de defectos bien definido (que incluya las propiedades del informe de defectos) y un equipo de gestión de defectos comprometido son necesarios para una gestión de defectos eficaz y eficiente.

Particularidades de la Gestión de Defectos en Equipos Ágiles

La gestión de defectos en las organizaciones que utilizan el Desarrollo Ágil de Software suele ser ligera y/o menos formal que en los modelos de desarrollo secuencial. Si los equipos ágiles están en ubicación común o disponen de medios de comunicación bien establecidos, la información sobre un defecto o fallo suele intercambiarse entre probadores, representantes del cliente y desarrolladores sin necesidad de un informe de defecto formal. Sin embargo, deberían crearse informes de defecto en los siguientes casos:

• Defectos que bloqueen otras actividades del sprint en curso (es decir, desarrollo, pruebas u otras) y que no puedan solucionarse inmediatamente dentro del equipo ágil.
• Defectos que no puedan resolverse dentro de la misma iteración. Algunos equipos ágiles tienen la norma de crear un informe de defecto si este no puede resolverse durante el día en que se encuentra el fallo.
• Defectos que deben ser resueltos por o en cooperación con otros equipos en organizaciones multiequipo.
• Defectos que deben ser resueltos por un proveedor.
• Defectos para los que se solicita explícitamente un informe de defecto (por ejemplo, cuando un desarrollador no puede trabajar inmediatamente en su solución).

La práctica habitual consiste en añadir los defectos que no pueden resolverse dentro de la misma iteración a la lista de trabajo acumulado del producto, de modo que puedan priorizarse entre otros defectos e historias de usuario para una iteración posterior.

Aunque las bases de la gestión de defectos deben establecerse en la estrategia de prueba de una organización, muchos aspectos, como el nivel de formalidad, los desencadenantes de la creación de un informe de defectos y los atributos de los defectos que deben capturarse, pueden dejarse al acuerdo entre los miembros del equipo ágil. En general, el nivel de formalidad de la gestión de defectos y el enfoque para crear informes de defectos deben reflejar lo siguiente:

• Ubicación común de los miembros del equipo.
• La distribución de los miembros del equipo por zonas horarias.
• El número de equipos que cooperan en el desarrollo del producto.
• Madurez del equipo o equipos.
• Tamaño del equipo o equipos.
• Riesgos asociados al producto.
• Requisitos legales, contractuales o de otro tipo (si son aplicables).

La decisión final del equipo ágil sobre los detalles de la gestión de defectos debe documentarse siempre (por ejemplo, con directrices en una herramienta de gestión de conocimientos).

Retos de la Gestión de Defectos en el Desarrollo Híbrido de Software

En la práctica, es habitual que varios equipos colaboren en la entrega del sistema o sistema de sistemas. Los ejemplos incluyen el desarrollo ágil de software cuando un cliente utiliza el desarrollo ágil de software y uno de sus proveedores utiliza un modelo de desarrollo secuencial, o cuando una organización que utiliza un modelo de desarrollo secuencial requiere la entrega de un subsistema por parte de un equipo que utiliza el desarrollo ágil de software. Un entorno multiequipo de este tipo plantea varios retos:

• El alineamiento sobre los atributos de los defectos y las herramientas a utilizar para la gestión de defectos: En un escenario ideal, todos los equipos utilizan una misma herramienta de gestión de defectos. En la práctica, es habitual que cada equipo utilice una herramienta de gestión de defectos diferente, especialmente cuando varios equipos de proveedores contribuyen a la entrega del proyecto. En estos casos es bueno establecer una sincronización entre las herramientas de gestión de defectos (preferiblemente de forma automática).
• Priorización de defectos: El propietario o propietarios de producto deben participar en las reuniones de gestión de defectos y buscar activamente información sobre las consecuencias y los riesgos asociados a los defectos. Las reuniones de gestión de defectos deben celebrarse con más frecuencia en el desarrollo ágil de software que en los modelos de desarrollo secuencial para seguir el ritmo de entrega de incrementos de producto más rápido del equipo ágil. Sin embargo, estas reuniones pueden ser más breves con equipos ágiles. A veces es beneficioso que un grupo más pequeño de implicados de la gestión de defectos tenga la última palabra sobre la priorización de los defectos.
• Alineamiento y transparencia del plan de prueba para el nuevo desarrollo y la corrección de defectos: El trabajo de todos los equipos debe alinearse con el mismo plan de proyecto, independientemente de que utilicen modelos de desarrollo ágil de software o de desarrollo secuencial. Todos los entregables, incluidas las correcciones de defectos, deben alinearse con este plan de proyecto. Se puede lograr una mejor alineación mediante la participación activa de los miembros de todos los equipos en el proceso de planificación (por ejemplo, la participación de los equipos del modelo de desarrollo secuencial en las reuniones de desarrollo ágil de software en las que se discuten y priorizan los defectos). La transparencia de los planes de desarrollo puede mejorarse compartiéndolos entre los equipos (por ejemplo, a través de cuadros de mando o de la lista de tareas pendientes del producto).

Información del Informe de Defecto

La información de un informe de defecto debería ser suficiente para los siguientes fines:

• Gestión del informe de defecto a lo largo del ciclo de vida del defecto.
• Evaluación del estado general del proyecto, especialmente en términos de calidad del producto, y del avance de las pruebas.
• Evaluación del estado de un incremento de producto en términos de calidad del producto.
• Evaluación de la capacidad del proceso.

La información necesaria para la gestión de defectos y el estado del proyecto puede variar en función del momento en que se detecte el defecto en el ciclo de vida de desarrollo de software (CVDS). Además, los informes de defecto relacionados con características de calidad no funcionales pueden necesitar más información (por ejemplo, las condiciones de carga para las dificultades de rendimiento). Sin embargo, la información básica recopilada debe ser consistente en todo el ciclo de vida de desarrollo de software (CVDS) e, idealmente, en todos los proyectos de una organización para permitir una comparación de datos significativa.

En un informe de defecto se pueden recopilar muchos elementos de información. El jefe de prueba debe decidir qué información es la adecuada para una gestión de defectos eficaz en el contexto de un proyecto determinado. Debido al hecho de que cada atributo adicional aumenta el tiempo empleado en redactar el informe y puede aumentar la confusión de la persona que lo introduce, es aconsejable recopilar únicamente los datos que se necesitan para la gestión de defectos en el contexto dado y/o que se utilizarán para la mejora del proceso.

Para gestionar el informe de defecto en la mayoría de los entornos, es obligatorio lo siguiente:

• Un título del defecto con un breve resumen de la anomalía.
• Una descripción detallada de la anomalía que incluya preferiblemente los pasos para reproducir el fallo.
• Severidad del impacto sobre el sistema sujeto a prueba y/o los implicados del producto.
• Prioridad para solucionar la anomalía.

La herramienta de gestión de defectos suele generar otros elementos de datos adicionales importantes de forma automatizada:

• Identificador único para el informe de defecto.
• Fecha/hora de creación del informe de defecto.
• Nombre de la persona que descubrió y/o informó de la anomalía.
• Fase del proyecto y del ciclo de vida de desarrollo de software (CVDS) en la que se descubrió la anomalía.
• Estado actual del informe de defecto.
• Propietario actual (es decir, la persona asignada actualmente para trabajar en el defecto).
• Histórico de cambios, como la secuencia de acciones, incluyendo la información de fecha/hora, llevadas a cabo por los miembros del equipo del proyecto para aislar, reparar y confirmar el defecto como solucionado.
• Referencias (por ejemplo, al caso de prueba, a defectos conectados).

Dependiendo del contexto, también se puede recoger más información (por ejemplo, trazabilidad) en un informe de defecto (para más información, consulte la norma ISO/IEC/IEEE 29119-3). Los siguientes puntos agrupan la información en función de la finalidad prevista:

• Ayudar a la resolución de defectos: El subsistema o componente en el que se encuentra el defecto, el elemento de prueba específico y su número de versión en el que se observó la anomalía, o el entorno de prueba utilizado.
• Para evaluar el estado general del proyecto: Información para monitorizar el avance (por ejemplo, los riesgos, costes, oportunidades y beneficios asociados a la corrección o no del defecto, una descripción de cualquier solución provisional disponible o los requisitos afectados).
• Para evaluar el estado de un incremento de producto en términos de calidad: El tipo de defecto (normalmente correspondiente a una taxonomía de defectos), el producto de trabajo en el que se introdujo el defecto o la característica/subcaracterística de calidad afectada.
• Para evaluar la capacidad del proceso: Información para monitorizar la efectividad y eficiencia de los procesos de desarrollo (por ejemplo, la fase del ciclo de vida de desarrollo de software en la que se introdujo, detectó y eliminó el defecto, o la causa raíz del mismo).

Definición de las Acciones de Mejora del Proceso Utilizando la Información de los Informes de Defectos

Los informes de defecto pueden ser útiles para monitorizar el estado del proyecto e informar sobre el mismo. En el nivel de gestión de pruebas avanzado, los jefes de prueba deben ser conscientes de lo que significan los informes de defecto para evaluar la capacidad de los procesos de desarrollo y prueba del software.

La información sobre defectos debería apoyar las iniciativas de mejora del proceso que se discuten durante las retrospectivas. Algunos ejemplos son:

• Utilizar la información sobre las fases de introducción, detección y eliminación de defectos para evaluar la contención de fase y/o realizar un análisis del coste de la calidad con el objetivo de sugerir formas de mejorar la efectividad de la detección de defectos en cada fase y minimizar el coste asociado a los mismos.
• Utilizar la información sobre la fase de introducción para analizar las etapas en las que se introduce el mayor número de defectos, con el fin de habilitar mejoras específicas para la prevención de defectos.
• Utilizar la información sobre la causa raíz de los defectos para determinar las razones subyacentes de la introducción de defectos, a fin de habilitar mejoras del proceso que reduzcan el número total de errores.
• Utilizar la información sobre la ubicación de los defectos para realizar un análisis de agrupamiento de defectos, comprender mejor los riesgos técnicos (para las pruebas basadas en el riesgo) y habilitar la refactorización de los componentes problemáticos.
• Utilizar información sobre defectos reabiertos para evaluar la calidad de las implementaciones de depuración y corrección.
• Utilizar la información sobre defectos duplicados y rechazados para evaluar la calidad de la creación de los informes de defecto y optimizar la preparación del equipo de pruebas.
• Permitir mejoras del proceso que reduzcan el número total de defectos mediante la introducción de medidas proactivas para evitar errores por adelantado.

En algunos casos, los equipos deciden no hacer un seguimiento de los defectos encontrados durante algunas o todas las fases del ciclo de vida de desarrollo de software (CVDS). Aunque esto se hace a menudo apelando a la eficiencia y en aras de reducir la sobrecarga del proceso, reduce enormemente la visibilidad de las capacidades del proceso de desarrollo y prueba del software. Esto hace que las mejoras sugeridas anteriormente sean difíciles de llevar a cabo debido a la falta de datos de apoyo fiables.

Fuente: Programa de estudios del ISTQB ALTM v3.0