¿Cómo manejar un problema menor encontrado en un proyecto que finalizó? [cerrado]

Fondo

Hace aproximadamente seis meses, aprobamos la finalización de un proyecto de software con un cliente externo y el presupuesto restante para ese proyecto se filtró nuevamente a otros proyectos. Estaba revisando el proyecto para refinar la documentación cuando me di cuenta de que una parte no crítica del software no se comportaría como se esperaba. Una prueba de una sola unidad no cambiaría un valor correctamente, lo que provocaría que la prueba siempre pasara incluso si el sistema cambiara de tal manera que fallara. No estaba seguro de cómo manejar esta situación ya que el proyecto ha terminado oficialmente y ya no estamos recibiendo fondos para trabajar en él. La prueba defectuosa no impide que el software funcione según lo previsto.

Solucionar el problema sería lo suficientemente trivial, pero implementarlo en el sistema del cliente requeriría un proceso largo que implicaría mucho más trabajo que solo hacer la solución.

Pregunta

En general, ¿cuál es la mejor manera de manejar este tipo de situación? Sé que la respuesta de la gerencia será simplemente dejarlo, pero siento que dejarlo sin que nadie sepa que sería lo incorrecto. Por otro lado, siento que informar a la gerencia sobre esto sería una pérdida de tiempo, especialmente porque ya no nos pagan por trabajar en este proyecto y es un problema tan intrascendente.

Ediciones

Con respecto a la respuesta de Erik:

Tenemos un sistema de tickets donde se filtran las solicitudes de soporte y las solicitudes de cambio. Las solicitudes de soporte se manejan y las solicitudes de cambio se colocan en un sistema diferente. El problema que veo con esto es que el cliente firmó y aceptó el proyecto después de la prueba y no tiene un acuerdo de soporte con nuestra empresa.

A single unit test would not change a value correctly, causing the test to always pass even if the system would change in such a way to make it fail.¿Es la prueba unitaria la que está defectuosa o el sistema que lo está?
La prueba unitaria en sí es defectuosa. Ni siquiera es la prueba unitaria completa, solo un caso de prueba dentro de esa prueba unitaria. Sería muy evidente dentro del sistema y para los usuarios si no manejara ese caso como se esperaba.
Ponga en espera: la forma en que maneja esto depende de las políticas de su empresa y cliente, lo que significa que solo debe preguntarle a su gerente qué debe hacer al respecto, si es que debe hacer algo.
El software que está "terminado" generalmente entra en modo de mantenimiento; registrar el problema quizás con una solución. Para este caso no necesita una nueva versión o un parche (típicamente al cliente no le importan las pruebas unitarias, solo que el software funcione); es solo un problema de mantenimiento.
El cliente ha aceptado el proyecto como completo. A menos que te pidan que hagas cambios, entonces el curso de acción correcto es seguir adelante. Es posible que desee informar al administrador del proyecto sobre el error que encontró y dejar que decida cómo manejarlo. Sospecho que entraría en un registro de correcciones para la próxima iteración

Respuestas (2)

Considérese un usuario y póngase en su lugar. Estoy seguro de que, incluso para un proyecto cerrado, hay algo configurado para cuando los usuarios encuentren problemas con el proyecto. Sigue sus pasos.

Probablemente esto signifique registrar el error con algún sistema que tenga internamente o con la mesa de soporte de su empresa. También podría significar informar al administrador de la cuenta.

No sé cómo funciona su empresa, pero asumo que su empresa sabe que ocurrirán errores y tiene un proceso para ellos, y puede plantear problemas técnicos de la misma manera.

Así es. Tenemos un sistema de tickets donde se filtran las solicitudes de soporte y las solicitudes de cambio. Las solicitudes de soporte se manejan y las solicitudes de cambio se colocan en un sistema diferente. El problema que veo con esto es que el cliente firmó y aceptó el proyecto después de la prueba y no tiene un acuerdo de soporte con nuestra empresa.
En ese caso, es probable que este problema no se resuelva, pero eso no importa. Lo que importa es que el problema se registre en caso de que más adelante necesite más trabajo y no se olvide.

Se le asigna la actualización de la documentación. Documente sus hallazgos e informe. Tal vez su documentación necesite una sección de "problemas conocidos" para incluir tales hallazgos. Esta sección puede crecer con el tiempo (condiciones especiales de tiempo de ejecución, no funciona con Windows x o la impresora y ...)

Queda entonces a discreción del cliente decidir cuándo desea realizar un trabajo adicional.

¿Cómo manejar un problema menor encontrado en un proyecto que finalizó? [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v