Realizar el seguimiento de los errores

Cuando ejecute pruebas para comprobar los requisitos, detectará errores sin duda alguna. Utilice el elemento de trabajo de error para describir y realizar un seguimiento del progreso de cada error que detecte.

Para obtener más información sobre cómo crear elementos de trabajo de error, vea Ejecutar pruebas manuales con Team Web Access. Cuando detecte errores, siga el proceso que se describe en este tema para asignarles un nivel de prioridad, asegurar su corrección y garantizar de que tendrá un registro del trabajo y de las decisiones implicados.

Evaluar errores

Las reuniones en las que se evalúan los errores deben celebrarse a intervalos fijos una vez iniciados el desarrollo y las pruebas del proyecto. La frecuencia y la duración de esas reuniones depende de cada caso.

Normalmente, estas reuniones las dirige un jefe de proyecto y en ellas participan responsables de equipo y quizás analistas de negocios así como partes interesadas que puedan abordar determinados riesgos del proyecto. El jefe de proyecto puede utilizar la consulta de errores activos para errores nuevos y errores que se han vuelto a abrir a fin de generar una lista de los errores que deben ser evaluados.

Antes de que se inicie la evaluación de los errores, se debe definir un conjunto de criterios para determinar qué errores deben corregirse y cuál es su nivel de prioridad. Normalmente, los criterios identifican la gravedad de los errores, errores asociados a características de valor significativo (o costo de oportunidad significativo por aplazamiento) u otros riesgos del proyecto.

Los criterios para la evaluación de errores deben almacenarse en la carpeta Documentos del proyecto de equipo. Con el tiempo, el documento se actualizará. Se supone que el proyecto tiene activado el control de versiones y que los criterios específicos que se usan en todo momento en el proyecto pueden recuperarse a fin de utilizarlos en las auditorías y las pruebas para las valoraciones.

En una fase temprana del proyecto, es probable que se decida corregir la mayoría de los errores evaluados. Sin embargo, a medida que progresa el proyecto, es posible que se suba el listón de los criterios de evaluación de errores para que se reduzca el número de errores que se deben corregir.

Elevar el listón de los criterios de evaluación de errores y permitir que los errores detectados no se corrijan es una solución de compromiso. Esta solución de compromiso indica que corregir el error es menos importante que cumplir con el ámbito, el presupuesto y la programación del proyecto.

Se deben usar los criterios para determinar qué errores se van a corregir y cómo establecer los campos Estado, Prioridad, Gravedad así como otros campos. De forma predeterminada, la plantilla proporciona cuatro prioridades: desde 1 para "se debe corregir" hasta 4 para "poco importante". Si cambia las definiciones de la plantilla de proceso, debe actualizar la orientación, el texto de ayuda y cualquier documento de criterios en consecuencia.

Corregir errores

Después de evaluar un error y asignarle un nivel de prioridad, se debe asignarlo a un desarrollador para que siga investigando.

El elemento de trabajo de error tiene una pestaña para los pasos de reproducción, que deben proporcionar todo lo necesario para reproducir el error. Sin embargo, también se puede utilizar IntelliTrace para que ayude a reproducir los errores difíciles. Para obtener más información sobre IntelliTrace, vea Seguimiento de la calidad del software.

Después de que el desarrollador tome una decisión sobre la acción que debe realizarse, deberá anotar dicha decisión en el elemento de trabajo de error.

Tomar una decisión referente a la corrección

Junto con otros miembros del equipo, es posible que el desarrollador recomiende una corrección que tenga implicaciones para otras secciones del código y requiera pruebas de regresión significativas. Todas las conversaciones relacionadas con la evaluación del riesgo que supone este tipo de corrección deben registrarse en el historial de los elementos de trabajo de error ya que de esta manera se documentan el análisis de decisiones y las pruebas de la administración de riesgos para una auditoría o una valoración según el método SCAMPI (Standard CMMI Appraisal Method for Process Improvement). Para obtener más información sobre CMMI, vea Información general de CMMI.

Actualizar y ejecutar pruebas unitarias para corregir el error

Las pruebas unitarias comprueban la implementación correcta de una unidad de código. Escribir y realizar pruebas unitarias identifica los errores antes de que se inicien las pruebas y, por consiguiente, ayuda a reducir el costo del control de calidad. Los desarrolladores deben escribir pruebas unitarias para todo el código que se escribirá como parte de la implementación de una tarea de desarrollo o de una corrección de errores. Para obtener más información, vea Comprobar código utilizando pruebas unitarias.

Quizás prefiera escribir la prueba unitaria antes de corregir el código según una estrategia de desarrollo de pruebas en primer lugar. Los desarrolladores de software ágil prefieren este tipo de estrategia. El modelo CMMI no exige que las pruebas unitarias se escriban en una secuencia determinada; solamente requiere que la funcionalidad se compruebe de manera eficaz.

Para una valoración según CMMI, es preciso demostrar que las pruebas unitarias fueron escritas y ejecutadas. Asegúrese de vincular las pruebas a los elementos de trabajo de tarea para la corrección de los errores y de vincular esas tareas al elemento de trabajo de error. De este modo, se puede realizar un seguimiento de las pruebas que busca el responsable de la valoración según SCAMPI.

Revisar y refactorizar el código para corregir el error

Se utiliza una revisión del código para asegurarse de que el código nuevo o cambiado cumple un nivel de calidad establecido antes de que se integre en la compilación diaria. Las consideraciones de calidad son normas de codificación, conformidad con la arquitectura y el diseño, rendimiento, legibilidad y seguridad. Las revisiones del código también proporcionan la visión adicional de otros desarrolladores sobre cómo se debería escribir el código. Para obtener más información sobre cómo revisar y refactorizar el código, vea Implementar tareas de desarrollo.

Cerrar errores

Una vez corregido un error, se debe asignarlo a un evaluador para que compruebe que se ha resuelto el problema antes de que se cierre el elemento de trabajo de error.

Comprobar una corrección

Para comprobar una corrección, el evaluador debe intentar reproducir el error, buscar un comportamiento inesperado adicional y, si es necesario, reactivar el error.

A la hora de comprobar la resolución de un error, es posible que el evaluador detecte que el error no se corrigió completamente o que no esté de acuerdo con la resolución. En este caso, debe hablar con la persona que resolvió el error, llegar a un acuerdo y posiblemente reactivar el error. Si reactiva un error, asegúrese de incluir las razones de la reactivación en la descripción del error para que quede constancia de esa información.

Cerrar un elemento de trabajo de error

Un error se cierra por muchas razones. En un caso simple, se comprueba que se ha corregido el error y se puede cerrar el error. Sin embargo, se puede aplazar un error a la versión siguiente del producto, demostrar que el error no se puede reproducir o confirmar que se trata de un duplicado. Cada uno de estos motivos se debe documentar y el error debe cerrarse correctamente para que no haya confusión alguna con respecto a la razón por la que se cierra.