Administración de defectos de software

Notas:

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

Elección de cómo el equipo realiza un seguimiento de los errores

Al determinar cómo realizará el seguimiento del error el equipo, tenga en cuenta los siguientes factores.

• Tamaño del equipo. Los equipos más pequeños querrán mantener una superficie ligera y realizar un seguimiento de los errores, ya que los requisitos pueden ser los más ligeros.
• Requisitos de la organización para realizar un seguimiento del trabajo. Si el equipo tiene que realizar un seguimiento de las horas, el seguimiento de los errores a medida que las tareas se alinean con este requisito.
• Cómo el equipo organiza el trabajo. Si el equipo se basa en el trabajo pendiente del producto para ordenar el trabajo, el seguimiento de los errores a medida que los requisitos admiten esta actividad.
• Herramientas que el equipo quiere usar, como el panel Planeamiento, el gráfico de velocidad, la previsión, el paquete acumulativo y los planes de entrega. El seguimiento de errores a medida que las tareas impiden el uso de varias de estas herramientas.

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

Personalización del tipo de elemento de trabajo de error

Puede personalizar el tipo de elemento de trabajo de error o crear otros tipos de elementos de trabajo 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 en el formulario de elemento de trabajo
• Personalización de los estados de flujo de trabajo
• Agregar reglas condicionales
• Elija el nivel de trabajo pendiente que aparece en el tipo de elemento de trabajo.

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

Agregar o capturar errores

Puede definir errores de varias herramientas de Azure DevOps diferentes. Estos incluyen trabajo pendiente y paneles y herramientas de prueba.

Adición de un error desde el trabajo pendiente o la placa

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

• Agregar un error del trabajo pendiente del producto

  

• Agregar un error del trabajo pendiente del producto

  

Agregar un error desde el trabajo pendiente de sprint o el panel de tareas

Si el equipo decide administrar errores con tareas ,puede definir errores desde el panel Kanban, el trabajo pendiente del producto, el trabajo pendiente de Sprint o el panel de tareas de Sprint. Agregue un error como elemento secundario a un elemento de trabajo pendiente del producto.

• Adición de un error secundario vinculado desde el panel Kanban
  Un error se agrega de la misma manera que se agrega una tarea a un elemento de trabajo pendiente. Para más información, consulte Agregar tareas o elementos secundarios como listas de comprobación.

  

• Agregar un error secundario vinculado desde el trabajo pendiente de Sprint
  Agrega un error de la misma manera que agrega una tarea a un trabajo pendiente de Sprint. Para más información, consulte Adición de tareas a elementos de trabajo pendiente.

  

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 portal web Test Runner y la extensión Comentarios & de prueba.

• Test Runner:al ejecutar pruebas manuales, puede elegir Crear error. Para más información, consulte Ejecución de pruebas manuales.

  

• Prueba Extensión de comentarios:al ejecutar pruebas exploratorias, puede elegir Crear error o Crear tarea. Para obtener más información, consulte Pruebas exploratorias con la extensión Test Feedback Extensión de comentarios

Ciclo de vida de errores y estados de flujo de trabajo

Al igual que con todos los demás tipos de elementos de trabajo, el tipo de elemento de trabajo Error 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,Scrumy CMMI.

Agile	Scrum	CMMI

En el caso de los errores de Scrum, cambie el estadode Confirmado (similar a Activo)a Listo. Para Agile y CMMI, primero debe resolver el error, lo 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 resolver o cerrar un error, se puede reactivar estableciendo el estado en Confirmado o Activo.

Comprobación de una corrección

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

Al comprobar una resolución de errores, es posible que encuentre que el error no se ha corregido o que no está de acuerdo con la resolución. En este caso, analice el error con la persona que lo resolvió, llegar a un acuerdo y, posiblemente, reactivar el error. Si vuelve a activar un error, incluya los motivos para reactivar el error en la descripción del error.

Cerrar un error

Una vez comprobado como corregido, se cierra un error. Sin embargo, también puede cerrar un error por uno de estos motivos:

• Aplazado: aplazamiento de una corrección hasta la próxima versión del producto
• Duplicado: el error ya se ha notificado, puede vincular cada error con el duplicado o duplicado del tipo de vínculo y cerrar uno de los errores.
• Tal como está diseñado: la característica funciona según lo diseñado
• 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
• Copiada en trabajo pendiente: se ha abierto un caso de usuario o PBI para realizar el seguimiento del error.

Enumeración y corrección de errores

La mayoría de los equipos, independientemente de la opción que elijan para realizar un seguimiento de los errores, definen una o varias consultas de errores. Con las consultas, puede enumerar errores activos, errores sin signo, errores obsoletos, tendencias de errores, etc. A continuación, puede agregar consultas y gráficos de consultas 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 que se corrigen para 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 su equipo, puede crear gráficos de estado o tendencias. También puede agregar el gráfico que crea a un panel.

Modo de triage en los resultados de la consulta

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

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

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 la prioridad. Para obtener más información, vea Triage work items.

Organización y asignación de errores a un sprint

Si el equipo realiza un seguimiento de los errores como requisitos,puede ver 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 completar las siguientes tareas:

• Organizar errores en el trabajo pendiente,clasificar la pila con otros elementos (la clasificación de la pila está deshabilitada cuando el filtrado está habilitado)
• Asignación de errores a un sprint desde el trabajo pendiente mediante el panel Planeamiento
• Errores primarios en características u otros elementos de trabajo pendiente de cartera mediante el panel Asignación
• Vea la acumulación de trabajos pendientes en los elementos de trabajo pendiente de cartera.

Si el equipo realiza un seguimiento de los errores como tareas,usará consultas administradas para enumerar y realizar una triejeción de los 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 los elementos enumerados en una consulta creada a partir de su trabajo pendiente de sprint correspondiente.

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

Estas razones pueden hacer que los elementos de trabajo que pertenecen a la categoría de tareas 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 los errores y tareas que ha vinculado a un elemento de trabajo pendiente de producto primario (Scrum), caso de usuario (Agile) o requisito (CMMI) cuya ruta de iteración está establecida en el sprint aparecerán en la página de trabajo pendiente de sprint.
• La tarea o el 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 del 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 insertdas vinculadas a errores

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

Actualización del estado del error

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

• Si el equipo realiza un seguimiento de los errores como requisitos,use el panel Kanban como se muestra en la siguiente imagen. Para más información, consulte Empezar a usar el panel Kanban.

  

• Si el equipo realiza un seguimiento de los errores como tareas,use el panel de tareas. Para más información, consulte Actualización y supervisión del panel de tareas.

  

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 en función del estado de una columna de panel. Para obtener más información, consulte los artículos siguientes:

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

Para automatizar las acciones de selección, agregue reglas personalizadas al tipo de elemento de trabajo Error. Por ejemplo, puede agregar una regla como se muestra en la siguiente imagen. Esta regla especifica que se vuelva a asignar 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 Aplicación de reglas a estados de flujo de trabajo (proceso de herencia).

Integración entre Azure DevOps

Uno de los métodos usados por Azure DevOps para admitir la integración es vincular objetos a otros objetos. Además de vincular 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 extracción, como se muestra en la imagen siguiente.

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

Vinculación de elementos de trabajo al desarrollo

El control Desarrollo admite la vinculación y visualización de vínculos realizados a compilaciones, confirmaciones de Git y solicitudes de extracción. 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).

Vinculación de elementos de trabajo a versiones

El control Implementación admite vínculos a y la visualizació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.

Vinculación de elementos de trabajo a ejecuciones de canalización

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

Creación o edición de un elemento de trabajo tras un error de compilación

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

Supervisión del estado de error, las asignaciones y las tendencias

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

Para obtener más información sobre consultas, gráficos y paneles; vea Acerca de las consultas ygráficosadministradosy paneles .

Extensiones de Marketplace

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

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

Pruebe esto a continuación

Artículos relacionados

• Uso de plantillas para agregar y actualizar elementos de trabajo
• Movimiento, cambio de tipo o eliminación de elementos de trabajo
• Copia o clonación de un elemento de trabajo

Trabajo pendiente del producto y panel Kanban

• Trabajo pendiente, carteras y administración de proyectos agile
• Crear el trabajo pendiente
• Definición de características y epopeyas
• Organización del trabajo pendiente y asignación de elementos de trabajo secundarios a elementos secundarios
• Filtrado interactivo de los proyectos pendientes, paneles, consultas y planes
• Previsión del trabajo pendiente del producto
• Ajustar el trabajo pendiente

Panel kanban

• Acerca de los paneles y Kanban
• Inicio rápido del panel Kanban
• Volver a ordenar tarjetas
• Adición de tareas o elementos secundarios como listas de comprobación
• Procedimientos recomendados de Kanban

Trabajo pendiente de sprint y panel de tareas

• Prácticas recomendadas de scrum y trabajo con sprints
• Asignar elementos de trabajo pendiente a un sprint
• Adición de tareas
• Actualizar el panel de tareas

Integración dentro de Azure DevOps

• Vinculación de casos de usuario, problemas, errores y otros elementos de trabajo
• Seguimiento de un elemento de trabajo o una solicitud de extracción
• Configuración de números de ejecución o compilación

Recursos del sector

• Deuda técnica buena y mala (y cómo ayuda el TDD) de Perok Kniberg
• Administración de la deuda técnica publicada por Sven Peter Eberhard Wolff

Azure Boards | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

¿Cómo se realiza el seguimiento y la 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 solucione rápidamente para admitir implementaciones de software de alta calidad? Y, ¿cómo se hace un buen progreso en las nuevas características a la vez que se aborda su deuda técnica?

Como mínimo, necesita una manera de capturar los problemas de software, clasificarlos en la pila, asignarlos a un miembro del equipo y realizar un seguimiento del progreso. Querrá administrar los defectos de código de maneras que se alineen con las prácticas de Agile.

Para admitir estos escenarios, Azure Boards un tipo de elemento de trabajo Error. El tipo de elemento de trabajo Error comparte 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.

Entre las características adicionales para administrar errores se incluyen las siguientes ventajas:

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

Requisitos previos

Tipo de elemento de trabajo de error

En la imagen siguiente se muestra el tipo de elemento de trabajo Error para el proceso de Scrum. El tipo de elemento de trabajo Error para los procesos agile y CMMI realiza un seguimiento de 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.

Campos específicos de errores

El tipo de elemento de trabajo Error usa algunos campos específicos del error. Use los campos descritos en la tabla siguiente para capturar tanto el problema inicial como las de descubrimientos en curso. Para obtener información sobre los campos específicos del error de proceso de CMMI, vea Referencia de los errores,problemas y riesgos de los campos . Para obtener información sobre todos los demás campos, vea Índice de campos de elemento de trabajo.