srinidhi-lwt · July 8, 2019 20:45
diff --git a/bug_fixing_and_collaboration.txt b/bug_fixing_and_collaboration.txt
 # BUG FIXING

 1. First of all, I would look into the line number where the code has been broken and what is the exception thrown.
   Stack trace helps us to know how this erroneous method is executed. This gives me a context of the issue.

 2. Second, I would access the page or action as a customer/admin to know where and when we are facing this issue. 
   We need to know how the error occurred by doing this. Otherwise, we need to reproduce the error. 
   We get the frequency and severity of the issue or the bug by reproducing it.

 3. Remember, that we need to understand the system before changing the code.

 4. Thirdly, if I had written the code then I would fix it after knowing exactly how it happened or after reproducing it. 
   If I have not written the code then it's the responsibility of the author to fix it.
   Test cases needs to be updated according to the code change or logic change which will happen.

 5. I would test this fix locally and deploy it to staging. Make sure all test cases are green on staging too.
   Will make sure that the issue is fixed on staging too by testing it twice. 
   Have a peer-to-peer review and then deploy it to Production.

 6. The bug is fixed only when it's fixed on Production!


 # COLLABORATION

 1. First of all, we need stop our development and understand the existing system about how it works. 
   We need to look into existing code and understand it briefly. 
   By doing this, we get to know the impact of our feature to the current system.
   
 2. Need to check whether existing test cases cover all use cases and edge cases properly. If not, we need to
   refactor those test cases for the existing code coverage.

 3. We need to write test cases first for our feature. It should be functional test cases to cover all use cases and edge
   cases. We need to follow 'RED-REFACTOR-GREEN' methodology.

 4. Write test cases which is RED at first, then write new or REFACTOR code to turn test cases into GREEN.

 5. We get to know if any use case or a edge case has been broken, when we run our test cases against our code 
   during development.

 6. We need to setup continous integration for test cases to run whenever we make a pull request or merge.

 7. Logging the error everytime with appropriate messages makes the developer's job easy to debug and fix the error.
	# BUG FIXING

	1. First of all, I would look into the line number where the code has been broken and what is the exception thrown.
	Stack trace helps us to know how this erroneous method is executed. This gives me a context of the issue.

	2. Second, I would access the page or action as a customer/admin to know where and when we are facing this issue.
	We need to know how the error occurred by doing this. Otherwise, we need to reproduce the error.
	We get the frequency and severity of the issue or the bug by reproducing it.

	3. Remember, that we need to understand the system before changing the code.

	4. Thirdly, if I had written the code then I would fix it after knowing exactly how it happened or after reproducing it.
	If I have not written the code then it's the responsibility of the author to fix it.
	Test cases needs to be updated according to the code change or logic change which will happen.

	5. I would test this fix locally and deploy it to staging. Make sure all test cases are green on staging too.
	Will make sure that the issue is fixed on staging too by testing it twice.
	Have a peer-to-peer review and then deploy it to Production.

	6. The bug is fixed only when it's fixed on Production!


	# COLLABORATION

	1. First of all, we need stop our development and understand the existing system about how it works.
	We need to look into existing code and understand it briefly.
	By doing this, we get to know the impact of our feature to the current system.

	2. Need to check whether existing test cases cover all use cases and edge cases properly. If not, we need to
	refactor those test cases for the existing code coverage.

	3. We need to write test cases first for our feature. It should be functional test cases to cover all use cases and edge
	cases. We need to follow 'RED-REFACTOR-GREEN' methodology.

	4. Write test cases which is RED at first, then write new or REFACTOR code to turn test cases into GREEN.

	5. We get to know if any use case or a edge case has been broken, when we run our test cases against our code
	during development.

	6. We need to setup continous integration for test cases to run whenever we make a pull request or merge.

	7. Logging the error everytime with appropriate messages makes the developer's job easy to debug and fix the error.