-1

Background

About six months ago we had sign-off for the completion of a software project with an external client and the remaining budget for that project was filtered back into other projects. I was revisiting the project to refine the documentation when I realised a non-critical part of the software wouldn't behave as intended. 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. I was unsure how to handle this situation as the project has officially ended and we are no longer receiving funding to work on it. The faulty test doesn't stop the software from working as intended.

Fixing the issue would be trivial enough, but to have it deployed on the customer's system would require a lengthy process to be triggered which would involve much more work than just making the fix.

Question

In general, what is the best way to handle this sort of situation? I know the answer from management will be to just leave it, but I feel like just leaving it without letting anybody know would be the wrong thing to do. On the other hand, I feel like letting management know about this would be seen as time wasting, especially since we're no longer being paid to work on this project and it's such an inconsequential issue.

Edits

With regards to Erik's answer:

We have a ticketing system where support requests and change requests are filtered out. Support requests are handled and change requests are put into a different system. The issue I see with this is that the project was signed off and accepted by the customer after testing and they do not have a support agreement with our company.

|improve this question
  • 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. Is it the unit test that is defective or the system that is? – Y12K Oct 12 '17 at 9:36
  • The unit test itself is defective. It's not even the entire unit test, just one test case within that unit test. It would be very evident within the system and to users if it didn't handle that case as expected as well. – Longisland Oct 12 '17 at 9:39
  • Put on hold: how you handle this depends on the policies of your company and client, which means you should just ask your manager what, if anything, you should do about this. – Lilienthal♦ Oct 12 '17 at 10:09
  • 1
    Software that is "done" typically goes into maintenance mode; log the issue perhaps with a fix. For this case it does not need a new release or a patch (typically the customer does not care about the unit tests; just that the software works); it is only a maintenance issue. – Brandin Oct 12 '17 at 11:51
  • 2
    The client has accepted the project as complete. Unless they request you make changes then the correct course of action is to move on. You may want to make the project manager aware of the error you found and let them decide how to handle it. I suspect it would go in a log of fixes for the next iteration – IDrinkandIKnowThings Oct 12 '17 at 17:00
3

Consider yourself a user, and move into their shoes. I'm sure that, even for a closed project, there is something set up for when users encounter issues with the project. Follow their steps.

Probably this means logging the bug with either some system you have internally, or your company's support desk. It might also mean informating the account manager.

I don't know how your company works, but I assume your company knows bugs will happen and has a process for them, and you can raise technical issues in the same way.

|improve this answer
  • That's right. We have a ticketing system where support requests and change requests are filtered out. Support requests are handled and change requests are put into a different system. The issue I see with this is that the project was signed off and accepted by the customer after testing and they do not have a support agreement with our company. – Longisland Oct 12 '17 at 9:36
  • In that case, this issue will probably not be picked up, but that doesn't matter. What matters is that the issue gets logged in case at a later time it needs more work, and won't be forgotten. – Erik Oct 12 '17 at 9:38
3

You are assigned to update the documentation. Document your findings and report. Maybe your documentation needs a "known issues"-section to put such findings in. This section can grow over time (special run time-conditions, does not work with windows x or printer y ...)

It is then at the clients discretion to decide when he wants to get additional work done.

|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.