Replicating and fixing bugs

System administrators or users may find problems that developers can not reproduce or can not diagnose. I would like to describe my approach.

First step is to try to replicate the problem on the my own development machine which is usually very different from the original server. If I can replicate it then I can probably fix it and when it finally works for me it will probably work on the original server too.

If I can not reproduce it I usually try to get the same data (db dump, backups, etc.) and ask for the exact steps to reproduce it, preferably with screenshots. The full db dump is always the best way, unfortunately privacy regulations often prevent admins from sending it to me even in encrypted form.

The next step is to try to replicate the exact server environment – that is OS version, PHP, database, configurations, etc. If I can not replicate it on the same software then I might eventually give up and wait till somebody else manages to reproduce it or I have to keep reading the code until I find the bug.

If I manage to reproduce the problem on the same sw, but not on my own test server then the problem may be a PHP or database version specific bug or it may be outside of Moodle code. You would probably try to use different PHP and database version first, then search through respective release notes or bug trackers.

As you can see a lot of these diagnostics can be done easily by sysadmins that have access to the original data – of course they have to know a bit about PHP, SQL syntax and Moodle internals. The more time the reporter spends on a bug report the higher chance the bug gets fixed quickly.

In the next post I am planing to describe my typical security review, hopefully it will be a bit less boring,