The science of debugging

The Science Of DebuggingSusanth Kurunthil

SDLC

Analysis

Specifications

Design

Coding

Testing

Installation

Support

Debugging

Science of Debugging

Debugging is an art, not a science yet No prescribed process Intuitive Skills enhanced by experience Can’t estimate for sure!

This is an attempt to bring debugging closer to a science

Bugs

What is a bug? A defect that causes the system not

to behave in the expected way Why is a bug called a bug? Debugging

The process of making the system to behave in the expected way

The debugging process: Where to start?

Debugging Example

Microsoft SQL Server Query

select count(*) as EmpCount, Designation

from employee where department = ’15’

and status = 'Active' group by Designation order by designation asc

Debugging Example Microsoft SQL Server Query

/* this SQL statement prints the active employee count by designation for the department ‘i5’ */

select count(*) as EmpCount, Designation

from employee where department = ’15’

and status = 'Active' group by Designation order by designation asc

The Debugging Process

Understanding

Isolation

Analysis

Solution

Testing

Understanding Bugs

Understand Expected behavior Current behavior Bug attributes

Bug Attributes Behavior Severity Priority

Understanding Bugs

Bug Behavior Often referred to as ‘Type’ Examples

Crash Data loss Denial of service Functionality mismatch Cosmetic (Spell errors, alignment etc.)

Absolute attribute

Understanding Bugs

Severity Perceived end-user effect Relative attribute

Applies to the module only There could be a direct correlation

between Behavior and Severity Correlates to Priority as well

Understanding Bugs

Priority Project management attribute Relative attribute

Applies to the module only Applies to the current timeline

(milestone) There will be a direct correlation

between Severity and Priority Same bug could assume a different

priority at a different project stage

Understanding Bugs

Additional Attributes Reproducibility

Impacts Debugging and QA Solvability

Impacts Debugging

Isolation

Isolation Process of narrowing the Bug Scope Bug Scope: Bug’s occurrence space Affirmative Reference Point (ARP)

A reference point you are sure of! It worked fine till yesterday evening! It doesn’t crash if I input a value < 1000

Assumptions can be built on it Bug is isolated based on one or more

ARPs Redefine Bug Scope iteratively

Isolation

Who should do it? QA Developer/Debugger

QA responsibility Clear bug description One or more ARPs The narrower the Bug Scope, the

better! Developer responsibility

Sufficiently narrow the Bug Scope

Analysis

Look for Syntactical errors Semantic errors

Check FEB list Beware

Only symptoms could be here, problem might be somewhere else

Don’t jump to conclusions too early

Solution

Solve current problem Scan the code for same or similar

problems elsewhere and fix them also

Check for other problems in the bug scope

Update FEB (Frequently Encountered Bugs) list

Testing Test the fix Test the features and

functionalities you MIGHT have broken with this fix

Test the features and functionalities you MIGHT NOT have broken with this fix

Ensure this issue won’t come back to you again

QA: Test for all possible occurrences of this bug

Sub-Optimal Processes

Shooting from the hip

Understanding

Isolation

Solution

Testing

Sub-Optimal Processes

Shooting in the dark

Understanding

Solution

Testing

Prevention

Prevention is better than cure Applying debugging processes to

development Narrow Feature Scope Use ARP’s while developing features Check feature against the FEB list Test the new features, features

around it before declaring it to be complete

You save more time and energy!

Thank You