¿Deberíamos estar rastreando defectos en cosas que no sean el código?

Question

En varias ocasiones en mi carrera, alenté al personal con el que trabajé y/o logré rastrear defectos en artefactos del proceso de desarrollo distintos del código fuente (es decir, requisitos, pruebas, diseño). Cada vez que la solicitud ha sido recibida con asombro, confusión y resistencia. Me parece tan obvio que siempre estoy un poco sorprendido cuando la gente se resiste a la idea.

Lo que obtenemos de este ejercicio es una imagen de dónde se crean los errores y dónde se encuentran (en qué parte del proceso). Si construimos malos requisitos, entonces lo sabremos y podemos trabajar para mejorarlos.

¿Alguien más está recopilando información sobre defectos que no están en el código fuente?

Answer 1

Sí, realizar un seguimiento de todos ellos.

documentación, documentos de diseño, requisitos, etc.

también estoy tan sorprendido como cualquier otro cuando escucho "argumentos" en contra de ella.
Como mínimo, el sistema de seguimiento debería poder identificar dónde se encontró el defecto y qué parte del proceso se inyectó.

Answer 2

Sí, definitivamente. Los artefactos que rodean su código (modelos, especificaciones, doco, información de requisitos, casos de uso, etc.) pueden contener errores que afectan al código en sí.

Answer 3

Normalmente, los sistemas de seguimiento de errores suponen que son una lista de cosas que se deben corregir o implementar. El seguimiento de errores en los requisitos u otra documentación (por ejemplo, listas de tareas) no parece ser lo mismo. Es más una cuestión de mantener registros para que pueda tener problemas de tendencias y evaluar si está haciendo menos de ellos.

Los estoy rastreando, pero fuera de nuestro sistema de seguimiento de errores.

Answer 4

Bueno ... cualquier cosa que pueda mejorar, ¡haga lo que pueda para mejorar!

Tratarlo todo como el seguimiento de errores tiene sentido, la opinión variará, como se señala, pero usar un sistema de seguimiento daría una imagen coherente de todo, dejar las tareas asignadas, etc. Tal vez una demostración, una presentación de diapositivas o algo destinado a utilizar estos sistemas de una forma que va más allá del seguimiento del código fuente original: las imágenes convencen más que las palabras.

Answer 5

Normalmente he rastreado la fuente de todos los defectos. Pueden ser arreglados en el código, pero no necesariamente son causados ​​por eso.

Requisito incorrecto, requisito interpretado incorrectamente, mal diseño, desarrollador brainf * rt, documentación incorrecta, prueba incorrecta, prueba faltante, prueba obsoleta, código que no hace lo que hace el desarrollador, error de herramienta/compilador (muy raro, en mi opinión), construir el problema del sistema ...

Para mí, todos son "el sistema no hace lo que el cliente quiere que haga", y todos indican que se debe cambiar algo para poder hacer hace lo que el cliente quiere que haga. Discutir si es un defecto o característica, o un error del código fuente o algún otro problema que distrae de abordar los problemas para mí.

Answer 6

Absolutamente. Solo mira Ubuntu Bug #1.

Answer 7

Una gran sorpresa que nadie parece haber mencionado es comenzar una base de datos de malos olores y trampas para usar cuando se realizan revisiones por pares.

Este es un recurso invaluable para los compañeros que realmente realizan la revisión.

Definitivamente vale la pena a largo plazo. Esto también debe ser un documento vivo, base de datos, etc., que se añade a como:

• errores son fijos
• como compañeros realizan opiniones y
• como nueva sangre llega a unirse al equipo (s) trayendo con ellos nuevos conocimientos y experiencia.

HTH.

aplausos,

Rob

Answer 8

eri es encantador. si su proceso es lo suficientemente bueno como para rastrear la fuente de defecto para organizarlo bien. ayuda a los clientes y diseñadores a calificar las restricciones en las que operan.

cliente: desarrollar robot para cortar el césped, donde todas las briznas de hierba se van a cortar a una longitud uniforme precisa

diseñador: vamos a utilizar unas tijeras de jardín de infantes zurdos montados perpendicular al suelo garantizar/cortes precisos nítidas

QA: los cortes son precisos.

cliente: ¿por qué el robot tarda 6 días en cortar hierba? Necesitamos adentro en 30 minutos o menos!

seguir claramente el origen del defecto de rendimiento puede ayudar a moldear las conversaciones y mejorar el proceso en el futuro.

Answer 9

Realizamos un seguimiento de errores en el software, errores en los documentos, errores en los dibujos, y solicitudes de nuevas características, todo utilizando la misma herramienta de seguimiento.