Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have software that for certain clients fails to download a file. The software is developed in Python and compiled into an Windows Executable. The cause of the error is still unknown but we have established that the client has an active internet connection. We suspect that the cause is due to the clients network setup. This error cannot be replicated in house.

What technique or methodology should be applied to this kind of specific error that cannot be replicated in house. The end goal is to determine the cause of this error so we can move onto the solution.

For example;

  • Remote Debugging: Produce a debug version of the software and ask the client to send back a debug output file. This involves alot of time (back and forth communication) and requires the client to work and act in a timely manor to be successful.
  • In-house debugging: Visit the client and determine their network setup, etc. Possibly develop a series of script tests before hand to run on the clients computer under the same network.
  • Other methodologies and techniques I am not aware of?
share|improve this question

2 Answers 2

Remote Debugging: Produce a debug version of the software and ask the client to send back a debug output file. This involves alot of time (back and forth communication) and requires the client to work and act in a timely manor to be successful.

The general idea here is correct, but there are two things to improve in this.

First, you should not need to produce a special "debug version" of your software - your client should be able to run your latest release of the application in a logging mode, without the need for reinstalling the thing - the logging feature should be always available for him if needed.

Second, you have to improve the logging mechanisms in your software - so you can minimize the communication effort for the client. So instead of "add a little logging here, send the client a different version of your software, he sends you a log back, you analyse the logs and change your software a little bit again", the cycle should be "when the problem occurs, the client sends you the basic log which is always activated, and if that's not enough, he switches on extensive logging, you get a huge log file containing each and everything which might be cause of the problem, and then you got ideally enough information to reproduce the problem or pinpoint the cause". Of course, in practice you might need still more than one cycle at when you start with this, but the goal should be to bring this down to "one".

There is also a nice tool included in Windows since Win-7 for logging what the user does in front of the client - the problem step recorder (psr.exe). See here for more details. This probably won't help you much if a server configuration is the real problem's cause, but maybe it is helpful to get a better understanding what happened at the client's site, without the need of physically visiting the client.

share|improve this answer
  • Remote debugging.

    Agreed, this involves a lot of time. But don't expect to find such error magically in a short amount of time with no effort.

    Agreed, this involves implication from the customer. But if the customer is not interested in solving the issue, there are chances it will remain unsolved.

  • Extensively verbose logging.

    If you have a mechanism which enables frequent updates, transparent for the end user (just like Chrome does), then you can frequently push changes with more and more logging, and pin out the issue this way. This also involves the ability to get the logs back to you.

    Depending on the product, you may force it to download a file (i.e. do the problematic operation) when the application loads, and to report the result.

  • On-site debugging (≠ in-house debugging).

    This may be the most difficult one, but may be relevant to some companies. Send one of your developers to the customer in order to study the issue. If he can be granted an administrative access to the problematic machine, resolving the issue may be easy and short enough, similarly to if the issue was reproduced in-house.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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