Debugging is a very challenging as well as an interesting aspect of Software Engineering. Debugging starts on a somber note when a defect or an issue is detected in a software product and ends on a positive note of identifying the cause. Hopefully fixing the defect follows.
I see project managers sulking at times on not having smart engineers – the so called human debuggers, in a team of bright developers. I am sure every one of you has come across such situations.
Great developers need not be successful debuggers. Sometimes we find QA engineers becoming very successful in debugging as compared to developers. More interestingly, the synergy emanates when a pair of engineers (a developer and a QA engineer) does debugging. We can call it ‘pair-debugging’ and am sure those who have spent days and nights in debugging would appreciate what it takes to debug errors that are very simple but, take huge efforts to debug. More interestingly, when a developer spends several hours on debugging an issue he naturally collaborates or joins hands with a QA engineer to get it straight.
Debugging starts when you raise questions and seek answers. Software engineers have to ask themselves several critical questions to ensure that they are able to take one step ahead in order to improve product quality while debugging. Here are such questions.
1. Is this bug reproducible in all environments (QA, Staging, Dev, and Prod)?
2. Do lookup tables in the development and testing environments have data similar as compared to production environment?
a. Could a fixed defect cause another defect due to data discrepancies?
b. Does the fix require any predefined data or parameters to be ensured at the target environment (test or production)?
c. Are we including this fact in the release note?
3. Can there be external factor(s) governing this defect? (For example, paper size in case of a defect found in a report)
4. Could there be similar errors in the system? Have we attempted to find similar errors –
a. in other operating systems, databases, browsers, etc?
b. across all combinations of Users and Roles?
c. in other Transactions or User Interfaces or Reports?
5. Have we applied the fix with all necessary components/changes? (Application code changes, additional components, database stored procedures, additional look-up data, and parameter file entries?)
6. What happens when we fix this bug? What is going to be its impact on end-user experience (of all users) or user-experience of business critical users or availability and performance of business critical modules?
7. How can I change my debugging approach to prevent such bugs from appearing again?
8. Does the defect fixing team know the right set of Configuration Items (Programs, Parameter Files, DB Scripts – Table Creation Scripts, Stored Procedures, etc) and related resources/interfaces (Printer, Paper Type, External Interfaces,) that correspond to this defect?
The synonyms of debug include ‘clear up’, ‘correct’, ‘sort out’, ‘repair’, ‘fix’, ‘mend’, etc. In practice, debugging does not stop as soon as a bug is found and fixed. There is more to it. This is just a lighter attempt to debug debugging. Any thoughts or experiences on debugging?