Definir, capturar, evaluar y administrar errores de software en Azure Boards

Azure DevOps Services | Azure DevOps Server 2022: Azure DevOps Server 2019 | TFS 2018

¿Cómo realiza el seguimiento y administración de defectos en el código? ¿Cómo se asegura de que los problemas de software y los comentarios de los clientes se aborden rápidamente para admitir implementaciones de software de alta calidad? Y, ¿cómo avanzas bien en las nuevas características y solucionas tu deuda técnica?

Como mínimo, necesita una manera de capturar los problemas de software, priorizarlos, asignarlos a un miembro del equipo y realizar un seguimiento del progreso. Además, quiere administrar los defectos del código de maneras que se alineen con sus prácticas ágiles.

Para admitir estos escenarios, Azure Boards proporciona un tipo de elemento de trabajo específico para realizar un seguimiento de defectos de código denominado Bug. Los elementos de trabajo de errores comparten todas las características estándar de otros tipos de elementos de trabajo con algunos más. Para obtener información general sobre las características estándar, consulte Seguimiento del trabajo con casos de usuario, problemas, errores, características y epopeyas.

Los errores también proporcionan las siguientes características adicionales:

  • Opciones para que cada equipo elija cómo desea realizar un seguimiento de los errores
  • Herramientas de prueba para capturar errores
  • Integración integrada en Azure DevOps para realizar un seguimiento de errores vinculados a compilaciones, versiones y pruebas

Nota

Los tipos de elementos de trabajo de errores no están disponibles con el proceso Básico. El proceso básico realiza un seguimiento de errores como Problemas y está disponible al crear un proyecto a partir de Azure DevOps Services o Azure DevOps Server 2019.1 o versiones posteriores.

Requisitos previos

  • Debe conectarse a un proyecto. Si aún no tiene un proyecto, cree uno.
  • Debe agregarse a un proyecto. Para agregarlo, agregue usuarios a un proyecto o equipo.
  • Para ver o modificar elementos de trabajo, debe tener los elementos de trabajo Ver en este nodo y Editar elementos de trabajo de este nodo establecidos enPermitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Para más información, consulte Establecimiento de permisos y acceso para el seguimiento del trabajo.
  • Para agregar nuevas etiquetas para agregar elementos de trabajo, debe tener acceso básico o superior y tener el nivel de proyecto Crear nuevos permisos de definición de etiqueta establecidos en Permitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Incluso si el permiso se establece explícitamente para una parte interesada, no tendrá permiso para agregar nuevas etiquetas, ya que están prohibidos a través de su nivel de acceso. Para más información, consulte Referencia rápida sobre el acceso a las partes interesadas.
  • Todos los miembros del proyecto, incluso aquellos que pertenecen al grupo Lectores , pueden enviar por correo electrónico elementos de trabajo.
  • Debe conectarse a un proyecto. Si aún no tiene un proyecto, cree uno.
  • Debe agregarse a un proyecto. Para agregarlo, agregue usuarios a un proyecto o equipo.
  • Para ver o modificar elementos de trabajo, debe tener los elementos de trabajo Ver en este nodo y Editar elementos de trabajo de este nodo establecidos enPermitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Para más información, consulte Establecimiento de permisos y acceso para el seguimiento del trabajo.
  • Para agregar nuevas etiquetas para agregar elementos de trabajo, debe tener acceso básico o superior y tener el nivel de proyecto Crear nuevos permisos de definición de etiqueta establecidos en Permitir. De forma predeterminada, el grupo Colaboradores tiene este conjunto de permisos. Incluso si el permiso se establece explícitamente para una parte interesada, no tendrá permiso para agregar nuevas etiquetas, ya que están prohibidos a través de su nivel de acceso. Para más información, consulte Referencia rápida sobre el acceso a las partes interesadas.
  • Todos los miembros del proyecto, incluso aquellos que pertenecen al grupo Lectores , pueden enviar por correo electrónico elementos de trabajo.

Sugerencia

Para notificar un error, un usuario debe tener como mínimo acceso a partes interesadas y Editar elementos de trabajo en este conjunto de permisos de nodo en Permitir para la ruta de acceso del área donde agregará el error. Para más información, consulte Establecimiento de permisos y acceso para el seguimiento del trabajo.

Tipo de elemento de trabajo de error

En la imagen siguiente se muestra el tipo de elemento de trabajo Bug para el proceso de Scrum. El tipo de elemento de trabajo Bug para los procesos agile y CMMI realiza un seguimiento de la información similar. Está diseñado para aparecer en el trabajo pendiente del producto junto con los requisitos o en el Panel de tareas junto con las tareas.

Nota

Las imágenes que ve desde el portal web pueden diferir de las imágenes que se ven en este artículo. Estas diferencias se derivan de las actualizaciones realizadas en la aplicación web, las opciones que usted o el administrador han habilitado y qué proceso se eligió al crear el proyecto: Agile, Basic, Scrum o CMMI. El proceso Básico está disponible con Azure DevOps Server 2019 Update 1 y versiones posteriores.

Tipo de elemento de trabajo de errores, formulario para el proceso de Scrum, Azure DevOps Server 2020 y servicio en la nube.

Captura de pantalla del tipo de elemento de trabajo bug, formulario para proceso de Scrum, Azure DevOps Server 2019 y TFS 2018.

Campos específicos de errores

El tipo de elemento de trabajo Error usa algunos campos específicos del error. Para capturar tanto el problema inicial como las detecciones en curso, use los campos descritos en la tabla siguiente. Para obtener información sobre los campos específicos del error definido para el proceso de integración del modelo de madurez de funcionalidad (CMMI), consulte Referencia de campo Errores, problemas y riesgos. Para obtener información sobre todos los demás campos, vea Índice de campo de elemento de trabajo.


Campo, grupo o pestaña

Uso


Pasos para reproducir
(nombre descriptivo=Pasos de reproducción)

Use para capturar suficiente información para que otros miembros del equipo puedan comprender completamente el defecto del código. Incluya las acciones realizadas para buscar o reproducir el error y el comportamiento esperado.


Información sobre el software y la configuración del sistema que son relevantes para el error y las pruebas que se van a aplicar. Los campos Información del sistema y Encontrado en Compilación se rellenan automáticamente al crear un error a través de una herramienta de prueba. Estos campos especifican información sobre el entorno de software y la compilación donde se produjo el error. Para más información, consulte Probar diferentes configuraciones.


Proporcione los criterios para cumplir antes de que se pueda cerrar el error. Antes de comenzar el trabajo, describa los criterios de aceptación del cliente lo más claramente posible. Los equipos deben usar estos criterios como base para las pruebas de aceptación y evaluar si un elemento se ha completado satisfactoriamente.


Especifica el nombre de la compilación que incorpora el código que corrige el error. Este campo debe especificarse al resolver el error. En el caso de Azure DevOps local, para acceder a un menú desplegable de todas las compilaciones que se han ejecutado, puede actualizar las FIELD definiciones de Found in Build and Integrated in Build para hacer referencia a una lista global. La lista global se actualiza automáticamente con cada compilación que se ejecuta. Para más información, consulte Consulta basada en campos de integración de compilación y prueba.
Para obtener información sobre cómo definir números de compilación, consulte Opciones de formato de número de compilación.


  • 1: El producto requiere una resolución correcta del elemento de trabajo antes de que se envíe y se solucione pronto.
  • 2: El producto requiere una resolución correcta del elemento de trabajo antes de que se envíe, pero no es necesario abordarlo inmediatamente.
  • 3: La resolución del elemento de trabajo es opcional en función de los recursos, el tiempo y el riesgo.

Una clasificación subjetiva del impacto de un error o elemento de trabajo en el proyecto o sistema de software. Por ejemplo: si un vínculo remoto dentro de la interfaz de usuario (un evento poco frecuente) hace que una aplicación o una página web se bloquee, es posible que especifique gravedad = 2 - Alta y Prioridad = 3. Los valores permitidos y las directrices sugeridas son:

  • 1 - Crítico: Debe corregir. Un defecto que provoca la terminación de uno o varios componentes del sistema o el sistema completo, o provoca daños en los datos extensos. Además, no hay métodos alternativos aceptables para lograr los resultados necesarios.
  • 2 - Alto: Considere la posibilidad de corregir. Un defecto que provoca la terminación de uno o varios componentes del sistema o el sistema completo, o provoca daños en los datos extensos. Sin embargo, existe un método alternativo aceptable para lograr los resultados necesarios.
  • 3 - Medio: (Valor predeterminado) Defecto que hace que el sistema genere resultados incorrectos, incompletos o incoherentes.
  • 4 - Baja: defectos menores o cosméticos que tienen soluciones alternativas aceptables para lograr los resultados necesarios.

El control Implementación admite vínculos y presentación de versiones que contienen elementos de trabajo. Para usar el control, debe habilitar la configuración de la versión. Para más información, consulte Vincular elementos de trabajo a versiones más adelante en este artículo.


El control Desarrollo admite vínculos a y visualización de vínculos realizados a objetos de desarrollo. Estos objetos incluyen confirmaciones de Git y solicitudes de incorporación de cambios, o conjuntos de cambios de TFVC y elementos con versiones. Puede definir vínculos desde el elemento de trabajo o desde las confirmaciones, las solicitudes de incorporación de cambios u otros objetos de desarrollo. Para más información, consulte Vinculación de elementos de trabajo al desarrollo más adelante en este artículo.


Notas:

1 Para cambiar la selección del menú o la lista de selección, consulte Personalización de la experiencia de seguimiento del trabajo. El método de personalización depende del modelo de proceso usado por el proyecto.

Elección del modo en que el equipo realiza un seguimiento de los errores

El equipo puede realizar un seguimiento de errores como requisitos o como tareas. Para admitir la elección del equipo, tenga en cuenta los siguientes factores.

  • Tamaño del equipo. Los equipos más pequeños pueden mantener una superficie ligera mediante el seguimiento de errores como requisitos.
  • Requisitos de la organización para realizar un seguimiento del trabajo. Si es necesario que el equipo realice un seguimiento de las horas, elija realizar el seguimiento de errores como tareas.
  • Cómo organiza el equipo el trabajo. Si el equipo se basa en el trabajo pendiente del producto para priorizar el trabajo y agregar errores, realice un seguimiento de los errores como requisitos.
  • Herramientas que el equipo quiere usar, como el panel Planificación, el gráfico de velocidad, la previsión, la acumulación y los planes de entrega. El seguimiento de errores como tareas impide el uso de varias de estas herramientas.

En la tabla siguiente se resumen las tres opciones que los equipos tienen que realizar un seguimiento de errores. Para obtener más información y establecer la opción para el equipo, consulte Mostrar errores en trabajos pendientes y paneles.


Opción

Elija cuando quiera...


Seguimiento de errores como requisitos

Nota

  • Los errores se asignan a la categoría de requisitos

Seguimiento de errores como tareas

  • Estimación del trabajo de errores similares a las tareas
  • Actualizar el estado de error en los paneles de tareas de sprint
  • Vinculación de errores a requisitos como elementos secundarios
  • Puede arrastrar y colocar errores en el panel Planificación para asignar errores a un sprint

Nota

  • Los errores se asignan a la categoría de tarea
  • Casos de usuario (Agile), Elementos de trabajo pendiente de producto (Scrum) o Requisitos (CMMI) son el tipo de elemento de trabajo primario natural para errores
  • Los errores no estarán visibles en los planes de entrega

Los errores no aparecen en trabajos pendientes ni en paneles

  • Administración de errores mediante consultas

Nota

  • Los errores están asociados a la categoría de errores y no aparecerán en trabajos pendientes ni en paneles.
  • Los errores no estarán visibles en trabajos pendientes, paneles, trabajos pendientes de sprint, tablas de tareas ni planes de entrega
  • No se pueden arrastrar y colocar errores en el panel Planificación para asignar errores a un sprint

Personalización del tipo de elemento de trabajo

Puede personalizar el error y otros tipos de elementos de trabajo. O bien, cree tipos personalizados para realizar un seguimiento de los problemas de software o los comentarios de los clientes. Con todos los tipos de elementos de trabajo, puede personalizar los siguientes elementos:

  • Agregar o quitar campos personalizados
  • Agregar controles personalizados o pestañas personalizadas dentro del formulario de elemento de trabajo
  • Personalización de los estados de flujo de trabajo
  • Adición de reglas condicionales
  • Elija el nivel de trabajo pendiente en el que aparecen los elementos de trabajo

Antes de personalizar el proceso, se recomienda revisar Configurar y personalizar Azure Boards.

Para personalizar el proceso concreto, consulte Personalización de un proceso de herencia.

Para personalizar el proceso concreto, consulte Personalización del modelo de proceso XML local.

Adición o captura de errores

Puede definir errores de varias herramientas de Azure DevOps diferentes. Estos incluyen trabajos pendientes y paneles y herramientas de pruebas.

Sugerencia

De forma predeterminada, el campo Título es el único campo obligatorio al crear un error. Puede agregar rápidamente errores de la misma manera que agregue casos de usuario o elementos de trabajo pendiente de productos mediante Azure Boards. Si desea hacer que algunos campos sean necesarios, házlo agregando reglas condicionales basadas en un cambio de estado. Para más información, consulte Agregar una regla a un tipo de elemento de trabajo (proceso de herencia).

Adición de un error desde el trabajo pendiente o el panel

Si el equipo decide administrar errores con requisitos, puede definir errores del trabajo pendiente del producto o de la placa Kanban. Para obtener más información, consulte Creación del trabajo pendiente del producto o Empezar a usar la placa Kanban.

  • Adición de un error desde el trabajo pendiente del producto

    Captura de pantalla para agregar un error del trabajo pendiente del producto, Agregar error.

  • Adición de un error desde el trabajo pendiente del producto

    Captura de pantalla para agregar un error desde el panel Kanban, Agregar error.

Sugerencia

Al agregar un error del trabajo pendiente del producto o del panel Kanban, el error se asigna automáticamente a la ruta de acceso del área predeterminada y la ruta de acceso de iteración definidas para el equipo. Para más información, consulte Valores predeterminados del equipo a los que hacen referencia los trabajos pendientes y los paneles.

Adición de un error desde el trabajo pendiente de sprint o el Panel de tareas

Si el equipo decide administrar errores con tareas, puede definir errores de la placa Kanban, el trabajo pendiente del producto, el trabajo pendiente de Sprint o el Panel de tareas de Sprint. Agrega un error como elemento secundario a un elemento de trabajo pendiente de producto.

Creación de un error a partir de una herramienta de prueba

Las dos herramientas de prueba que puede usar para agregar errores durante las pruebas incluyen el ejecutor de pruebas del portal web y la extensión Comentarios & de prueba.

Estados de ciclo de vida y flujo de trabajo de errores

Al igual que con todos los demás tipos de elementos de trabajo, el tipo de elemento de trabajo Bug tiene un flujo de trabajo bien definido. Cada flujo de trabajo consta de tres o más estados y un motivo. Los motivos especifican por qué el elemento ha pasado de un estado a otro. En las imágenes siguientes se muestra el flujo de trabajo de errores predeterminado definido para los procesos agile, Scrum y CMMI .

Agile Scrum CMMI
Estados de flujo de trabajo de errores, plantilla de proceso de Agile Estados de flujo de trabajo de errores, plantilla de proceso de Scrum Estados de flujo de trabajo de errores, plantilla de proceso de CMMI

En el caso de los errores de Scrum, cambia el estado de Confirmado (similar a Activo) a Listo. Para Agile y CMMI, primero resuelve el error y selecciona un motivo que indica que el error se ha corregido. Normalmente, la persona que creó el error comprueba la corrección y actualiza el estado de Resuelto a Cerrado. Si se ha encontrado más trabajo después de que se haya resuelto o cerrado un error, puede volver a activarlo estableciendo el estado en Confirmado o Activo.

Nota

Anteriormente, el tipo de elemento de trabajo de error de proceso de Agile tenía una regla que reasignaba el error a la persona que la creó. Esta regla se ha quitado del proceso predeterminado del sistema. Para restablecer esta automatización, agregue una regla. Para ver un proceso de herencia, consulte Aplicar reglas a los estados de flujo de trabajo, Automatizar la reasignación en función del cambio de estado.

Comprobación de una corrección

Para comprobar una corrección, un desarrollador o evaluador intenta reproducir el error y buscar un comportamiento más inesperado. Si es necesario, deben reactivar el error.

Al comprobar una corrección de errores, es posible que encuentre que el error no se corrigió o que podría estar en desacuerdo con la resolución. En este caso, analice el error con la persona que lo resolvió, venga a un acuerdo y, posiblemente, vuelva a reactivar el error. Si reactiva un error, incluya los motivos para reactivar el error en la descripción del error.

Cerrar un error

Cierra un error una vez comprobado como corregido. Sin embargo, también puede cerrar un error por uno de los siguientes motivos. Los motivos disponibles para seleccionar dependen del proceso del proyecto y de los estados de transición de errores.

Proceso ágil:

  • Diferido: aplazar la corrección de errores hasta la próxima versión del producto.
  • Corregido: el error se comprueba como corregido.
  • Duplicado: el error realiza un seguimiento de otro error definido actualmente. Puede vincular cada error con el tipo de vínculo Duplicado/Duplicado y cerrar uno de los errores.
  • Como diseñado: la característica funciona como está diseñada.
  • No se puede reproducir: las pruebas demuestran que el error no se puede reproducir.
  • Obsoleto: la característica del error ya no está en el producto.
  • Copiado en trabajo pendiente: se ha abierto un caso de usuario para realizar el seguimiento del error.

Proceso de Scrum:

  • No es un error: el error se comprueba que no es un error.
  • Duplicado: el error realiza un seguimiento de otro error definido actualmente. Puede vincular cada error con el tipo de vínculo Duplicado/Duplicado y cerrar uno de los errores.
  • Quitado del trabajo pendiente: se comprueba que el error no es un error. Quite el error del trabajo pendiente.
  • Trabajo finalizado: el error se ha comprobado como corregido.

Proceso de CMMI:

  • Diferido: aplazar la corrección de errores hasta la próxima versión del producto.
  • Duplicado: el error realiza un seguimiento de otro error definido actualmente. Puede vincular cada error con el tipo de vínculo Duplicado/Duplicado y cerrar uno de los errores.
  • Rechazado: se comprueba que el error no es un error.
  • Comprobado: el error se comprueba como corregido.

Sugerencia

Una vez que se ha cerrado un error y la corrección se publica activamente en las implementaciones, la práctica recomendada es no volver a abrirla nunca debido a la regresión. En su lugar, debe considerar la posibilidad de abrir un nuevo error y vincularlo al error cerrado anterior.

Siempre es recomendable describir más detalles para cerrar un error en el campo Discusión para evitar confusiones futuras sobre por qué se cerró el error.

Automatización del cierre de errores al combinar solicitudes de incorporación de cambios

Si el equipo usa un repositorio de Git, puede establecer el estado en errores vinculados y otros elementos de trabajo para cerrarse tras la combinación correcta de solicitudes de incorporación de cambios. Para obtener más información, consulte Establecer el estado del elemento de trabajo en la solicitud de incorporación de cambios más adelante en este artículo.

Enumeración y evaluación de errores

La mayoría de los equipos, sea cual sea la opción que elijan para realizar el seguimiento de errores, definan una o varias consultas de errores. Con las consultas, puede enumerar errores activos, errores sin asignar, errores obsoletos, tendencias de errores, etc. Después, puede agregar consultas y consultar gráficos a los paneles del equipo para supervisar el estado y el progreso de los errores.

Consultas de errores

Abra una consulta compartida o use el editor de consultas para crear consultas de errores útiles, como las siguientes opciones:

  • Errores activos por prioridad (State <> Done o State <> Closed)
  • Errores en curso (State = Committed o State = Active)
  • Errores para corregir una versión de destino (Tags Contains RTM)
  • Errores recientes: errores abiertos en las últimas tres semanas (Created Date > @Today-21)

Una vez que tenga las consultas de interés para el equipo, puede crear gráficos de estado o tendencias. También puede agregar el gráfico que cree a un panel.

Modo de evaluación de prioridades en los resultados de la consulta

Una vez que haya empezado a codificar y probar, querrá mantener reuniones periódicas de evaluación de prioridades para revisar y clasificar los errores. Normalmente, el propietario del proyecto ejecuta las reuniones de evaluación de prioridades de errores. Los líderes del equipo, los analistas de negocios y otras partes interesadas que pueden hablar sobre los riesgos específicos del proyecto asisten a las reuniones de evaluación de prioridades.

El propietario del proyecto puede definir una consulta compartida para errores nuevos y vueltos a abrir para enumerar los errores que se van a evaluar.

En la página de resultados de la consulta, puede subir y bajar rápidamente dentro de la lista de elementos de trabajo de errores mediante las flechas arriba y abajo. A medida que revise cada error, puede asignarlo, agregar detalles o establecer prioridad. Para más información, consulte Evaluación de prioridades de los elementos de trabajo.

Captura de pantalla del panel derecho Resultados de la consulta, Errores activos y Modo de evaluación de prioridades.

Organizar y asignar errores a un sprint

Si el equipo realiza un seguimiento de errores como requisitos, consulte la lista de errores activos del trabajo pendiente. Con la función de filtro, puede centrarse únicamente en errores. Desde el trabajo pendiente del producto, también puede realizar las siguientes tareas:

Si el equipo realiza un seguimiento de errores como tareas, use consultas administradas para enumerar y evaluar errores. A continuación, dentro de cada sprint, verá los errores asignados al sprint desde el trabajo pendiente de sprint o el Panel de tareas.

Elementos del panel de tareas frente a elementos de lista de consultas

Es posible que observe y se pregunte por qué los elementos que se muestran en un panel de tareas de sprint pueden diferir de una lista de consultas creada en un trabajo pendiente de sprint correspondiente.

Es posible asignar tareas o errores a una iteración, pero no tenerlos vinculados a un elemento de trabajo pendiente primario. Estos elementos se mostrarán en la consulta creada, pero es posible que no aparezcan en el propio Panel de tareas. El sistema ejecuta la consulta y, a continuación, aplica algunos procesos en segundo plano antes de mostrar elementos del Panel de tareas.

Estos motivos pueden hacer que los elementos de trabajo que pertenecen a la categoría de tarea no aparezcan en un trabajo pendiente de sprint o en un panel de tareas:

  • La tarea o el error no se han vinculado a un elemento de trabajo pendiente primario. Solo errores y tareas que ha vinculado a un elemento de trabajo pendiente de producto primario (Scrum), caso de usuario (Agile) o requisito (CMMI) con una ruta de acceso de iteración establecida en el sprint aparece en la página trabajo pendiente de sprint.
  • La tarea o error es un elemento primario de otra tarea o error, o el caso del usuario es un elemento primario de otro caso de usuario. Si ha creado una jerarquía de tareas, errores o casos de usuario, solo aparecen las tareas de nivel secundario o los casos de nivel secundario en la parte inferior de la jerarquía.
  • El elemento primario vinculado de la tarea o el error corresponde a un elemento de trabajo pendiente definido para otro equipo. O bien, la ruta de acceso del área del elemento de trabajo pendiente primario de la tarea o del error difiere de la ruta de acceso del área de la tarea o del error.

Creación de pruebas insertadas vinculadas a errores

Cuando el equipo realiza el seguimiento de errores como requisitos, puede usar el panel Kanban para agregar pruebas para comprobar las correcciones de errores.

Captura de pantalla del panel Kanban, 3 columnas que muestran pruebas insertadas agregadas y vinculadas a errores.

Actualizar el estado del error

Puede actualizar el estado del error arrastrando y colocando errores en una nueva columna de un panel.

Personalización de la placa para realizar un seguimiento de los estados intermedios

Puede agregar columnas intermedias para realizar un seguimiento del estado del error en la placa. También puede definir consultas que filtren según el estado de una columna de panel. Para más información, vea los siguientes artículos:

Automatización de la reasignación de errores en función del estado del flujo de trabajo

Para automatizar acciones de selección, agregue reglas personalizadas al tipo de elemento de trabajo Error. Por ejemplo, agregue una regla como se muestra en la imagen siguiente. Esta regla especifica que se reasigna un error a la persona que abrió el error una vez resuelto. Normalmente, esa persona comprueba que el error se ha corregido y cierra el error. Para más información, consulte Aplicar reglas a estados de flujo de trabajo (proceso de herencia).

Captura de pantalla de la regla definida para reasignar el error en función del estado resuelto.

Establecimiento del estado del elemento de trabajo en la solicitud de incorporación de cambios

Al crear una solicitud de incorporación de cambios, puede establecer el valor de estado de los elementos de trabajo vinculados en la descripción. Siga la sintaxis: {state value}: #ID. Al combinar la solicitud de incorporación de cambios, el sistema lee la descripción y actualiza el estado del elemento de trabajo. En el ejemplo siguiente, establecemos los elementos de trabajo #300 y #301 en Resuelto y #323 y #324 en Cerrado.

Captura de pantalla de la configuración del estado del elemento de trabajo en una solicitud de incorporación de cambios.

Nota

Esta característica requiere la instalación de Azure DevOps Server actualización 2020.1. Para más información, consulte notas de la versión de Azure DevOps Server 2020 Update 1 RC1, Boards.

Integración en Azure DevOps

Uno de los métodos que usa Azure DevOps para admitir la integración es vincular objetos a otros objetos. Junto con la vinculación de elementos de trabajo a elementos de trabajo, también puede vincular elementos de trabajo a otros objetos. Vincule a objetos como compilaciones, versiones, ramas, confirmaciones y solicitudes de incorporación de cambios, como se muestra en la imagen siguiente.

Imagen conceptual que muestra los tipos de vínculo usados para vincular elementos de trabajo para compilar y liberar objetos.

Puede agregar un vínculo desde el elemento de trabajo o desde los objetos de compilación y versión.

El control Desarrollo admite la vinculación y visualización de vínculos realizados en compilaciones, confirmaciones de Git y solicitudes de incorporación de cambios. O bien, cuando se usa un repositorio TFVC, admite vínculos a conjuntos de cambios y elementos con versiones. Al elegir el vínculo, se abre el elemento correspondiente en una nueva pestaña del explorador. Para más información, consulte Drive Git development from a work item (Impulsar el desarrollo de Git desde un elemento de trabajo).

Control de desarrollo en el formulario de elemento de trabajo con vínculos de ejemplo para compilar, solicitudes de incorporación de cambios y confirmaciones.

El control Implementación admite vínculos y presentación de versiones que contienen los elementos de trabajo. Por ejemplo, en la imagen siguiente se muestran varias versiones que contienen vínculos al elemento de trabajo actual. Puede expandir cada versión para ver detalles sobre cada fase. Puede elegir el vínculo de cada versión y fase para abrir la versión o fase correspondientes. Para más información, consulte Vinculación de elementos de trabajo a implementaciones.

Control de implementación en el formulario de elemento de trabajo con versiones de ejemplo.

Las canalizaciones a menudo se definen para ejecutarse automáticamente cuando se produce una nueva confirmación en un repositorio de Git. Los elementos de trabajo asociados a las canalizaciones de confirmación se mostrarán como parte de la ejecución de la canalización si personaliza la configuración de la canalización. Para más información, consulte Personalización de la canalización.

Captura de pantalla de configuración de canalización, vincular automáticamente los elementos de trabajo de esta ejecución desde la rama seleccionada.

Crear o editar un elemento de trabajo tras un error de compilación

Si usa canalizaciones clásicas (no YAML), puede crear elementos de trabajo en un error de compilación. Para obtener más información, consulte Opciones de compilación, Creación de un elemento de trabajo en caso de error.

Puede realizar un seguimiento del estado de los errores, las asignaciones y las tendencias mediante consultas que, a continuación, puede trazar y agregar a un panel. Por ejemplo, estos son dos ejemplos que muestran tendencias de errores activas por estado y errores activos por prioridad a lo largo del tiempo.

Captura de pantalla de dos gráficos de consultas de errores activos, Tendencias de errores por estado y prioridad.

Para obtener más información sobre consultas, gráficos y paneles; consulte Acerca de las consultas administradas y los gráficos y los paneles.

Uso de vistas de Analytics y el servicio Analytics para crear informes de errores

El servicio Analytics es la plataforma de informes de Azure DevOps, reemplazando la plataforma anterior basada en SQL Server Reporting Services.

Las vistas de análisis proporcionan filtros pregenerados para ver los elementos de trabajo. Se admiten cuatro vistas analíticas para la generación de informes de errores. Puede usar estas vistas tal como se definen o editarlas aún más para crear una vista personalizada filtrada.

  • Errores: todo el historial por mes
  • Errores: últimas 26 semanas
  • Errores: últimos 30 días
  • Errores: hoy

Para más información sobre el uso de vistas analíticas, consulte ¿Qué son las vistas de Analytics y Creación de un informe de errores activos en Power BI basado en una vista de Análisis personalizada?

Puede usar Power BI para crear informes más complejos que los que puede obtener de una consulta. Para más información, consulte Conexión con El conector de datos de Power BI.

Informes de errores de SQL Server predefinidos

Los siguientes informes son compatibles con los procesos agile y CMMI.

Estos informes requieren que haya configurado SQL Server Analysis Services y SQL Server Reporting Services para el proyecto. Para obtener información sobre cómo agregar informes de SQL Server para un proyecto, consulte Agregar informes a un proyecto.

Extensiones de Marketplace

Hay varias extensiones de Marketplace relacionadas con errores. Consulte Marketplace para Azure DevOps.

Para obtener más información sobre las extensiones, consulte Azure Boards extensiones desarrolladas por Microsoft.

Pruebe esto a continuación

Trabajo pendiente de producto y placa Kanban

Panel kanban

Trabajo pendiente de sprint y Panel de tareas

Integración en Azure DevOps

Recursos del sector