How to Fix Defect Effectively

How to Fix Defect Effectively

Understand the problem
Recreate the problem
Usually trying to recreate the problem is a good start.
Only we can recreate the problem, we can really make sure we know why this problem happen, why do find the root cause, It can help you to find the root cause, to isolate the problem, and it can make sure your change does really fix the problem.

May you have test team to help recreate the problem, still try to recreate the problem in your environment, this would be more time effective.

Ask customer or tester team how to recreate it, like what tests or operations they were doing.
Know more about the problem as possible as you can. Communicate well with customer and test team.
Get the bottom of the root cause.

1.         Never try to change the code before you figure out the real root cause.

2.         Isolate the problem and focus on the related code.

3.         List all possible causes, and examine them one by one.

4.         Add more log to help identify the root cause.

5.         If you are able to recreate the problem, you can add more log to help you to identify the root cause.

6.         Brain Storm.

Ask your team mate to help to brain storm on it.

7.         Write down your to-do-list for finding the root cause.

Fix the code

1.         Understand well the code you are trying to change.

Is there any special reason - we don't know yet, it is implemented like this? Why it doesn't work now.
Ask the originator to help to explain it.

2.         Choose the best solutions

Think whether there are other/alternative/better/simpler ways to fix this.
There are usually multiple ways to fix this problem, think them out, and compare them, make trade-off, and choose the best one that suits current situation.

3.         Know your fix well.

Know what it is trying to change, how to test your change.
Does your fix work well in all possible cases?
Know its side effects.
Beware of versioning problems
Will it break other things?
Know (and write down) possible breakage your code may introduce, pay attention to it, and use test to verify it.

4.         Use tools such as Findbugs, PMD etc to help avoid common programming errors.

Verify your fix.
Verify it fix this problem correctly.
Verify it doesn't introduce breakage.
Think about possible breakage it may introduce, and verify them.

Test your fix thoroughly to cover all possible situations.
Design the test cases to cover all good and error paths.
Write down the result of all test cases and analyze them.

Review your fix
Explain your fix clearly to your team mate, make sure they can understand the problem, agree the root cause, and understand your fix.
Explain the drawback of your fix, and ask for suggestions.

Debug It
The Core Debugging Process - Reproduce, diagnose, fix, reflect
Debugging Is More Than "Making the Bug Go Away"
Effective debugging requires that we take these steps:
1. Work out why the software is behaving unexpectedly.
2. Fix the problem.
3. Avoid breaking anything else.
4. Maintain or improve the overall quality (readability, architecture, test coverage, performance, and so on) of the code.
5. Ensure that the same problem does not occur elsewhere and can not occur again.

Understanding the problem and identifying the root cause is the cornerstone upon which everything else

Construct experiments, and observe the results.
Before start trying to reproduce the problem, hypothesizing about its cause, before make experiments, know What You’re Looking For, What is happening, and what should?
• Work on only one problem at a time.
Dig into the bug report.
Check Simple Things First
Ask whether there are similar problems seen and fixed before.
Reproduce
Reproducing the problem can help prove or disprove that your thoughts of the root cause is really root cause, can help to demonstrate your fix does work.
Ask your tester/users help (how) to recreate the problem.
Refining Your Reproduction
As Simple as Possible
Minimize the Time Required

Make Nondeterministic Bugs Deterministic
• Multithreading
Use sleep( ) method to force a thread to wait long enough to force a race condition to occur.

Automate the reproduction.
What If You Really Can’t Reproduce It?
Does It Really Exist?
Users don’t (normally) report bugs maliciously.

Work on a Different Problem in the Same Area
Get Others Involved
The best person to talk to is whoever reported the bug in the first place.
It can help to bring in someone who can attack the problem from an alternative direction.
Diagnose
Idealized process:
1. Examine what you know about the software’s behavior, and construct a hypothesis about what might cause it.
2. Design an experiment that will allow you to test its truth (or otherwise).
3. If the experiment disproves your hypothesis, come up with a new one, and start again.
4. If it supports your hypothesis, keep coming up with experiments until you have either disproved it or reached a high enough level of certainty to consider it proven.

• Construct hypotheses, and test them with experiments.
Experiments Must Prove or Disprove Something
Make sure you understand what your experiments are going to tell you. Your experiment must have a clear goal.
One Change at a Time
Keep a Record of What You’ve Tried
Periodically review what you’ve already tried and learned.

Ignore Nothing
If something unexpected happens, it means that some assumption you’re making is broken.
Anything that you don’t understand is potentially a bug.
Stratagems
Instrumentation the code
Divide and Conquer - binary chop
Leveraging Source Control when chase a regression
Focus on the Differences
Learn from Others, Google Searc
Explore the simple explanation/hypothesis first.
Use Debuggers

Validate Your Assumptions
Know what assumptions you’re making, and examine them critically.

Often the simple act of explaining the problem is all it takes for inspiration to strike.
Explaining your problem to someone else forces you to get your thoughts in order, enumerate your assumptions, and construct an argument from basic principles.
Let Problems Lie Fallow
Sleep on it, and Help your subconscious help you.
Change Something. Anything!

Persevere, there’s always a way through.
Validate Your Diagnosis
• Explain your diagnosis to someone else. Imagine that you are wrong—what mistake did you make?
Fix
There’s more to a good fix than just making the software behave correctly.
Make sure you know how you’re going to test it before designing your fix
Fix the Cause, Not the Symptoms
One logical change, one check-in.
Diff before check-in.
Get Your Code Reviewed
Reflect - Lesson Learned
Ask these questions: How the bug crept into the code? How Did It Ever Work? What Went Wrong?
Ensure it’ll Never Happen Again
Whether the code is leading people astray?
If you notice several examples of a particular problem, maybe the structure or the interface is making it too easy to make the same mistake repeatedly?

When a bug does slip through the cracks, we should learn as many lessons from it as possible and take whatever action we can to ensure that it doesn’t happen again.

Add identifying compatibility issues to your bug-fixing checklist.

Concurrency
Use sleep() or control exactly what order things happen in into your synchronization code to help reproduce concurreny-related bugs.
Avoid using sleep( ) when fixing concurrency bugs.
In concurrent software—making them less likely to happen is not an acceptable fix.

• Fixing performance bugs always starts with an accurate profile.
Suspect your own, ahead of third-party, code.
Software should be robust in production and fragile when debugging.

Resources:
Debug It!: Find, Repair, and Prevent Bugs in Your Code