Q: What is Defect?
Ans: Deviations from the requirement is k.a., Defect.
Deviations can be:
(a) Missing implementaion
(b) Wrong implementation
(c) Extra implementation
-----------------------------------------------

Q: What is Bug?
Ans: Informal/Fancy name given to the defect is Bug.
----------------------------------------------

Q: What is Failure?
Ans: A failure is the inability of a software system or component to perform its required functions within specified performance requirements
----------------------------------------------

Q: What is Error?
Ans: An error is a mistake, misconception, or misunderstanding on the part of a software developer. In the category of developer we include software engineers, programmers, analysts, and testers.
(a) Syntax
(b) Logical
(c) Runtime
----------------------------------------------

Q: What is Fault?
Ans: An incorrect step, process or data definition in a computer program which causes the program to perform in an unintended or unanticipated manner. A fault is introduced into the software as the result of an error.

==================================
========Defect Template=============

defect Template: The important, standard set of information which we should provide while logging the defect.

The sample Defect is:
The "Send" button in compose page is not working.

The defect template includes following sections:
1. title
2. Environment
3. Build Details
4. Steps to replicate
5. Expected Result
6. Actual Result
7. Additional Info

Example:
Title: Getting "Nullpointer" exception upon clicking "Send" button in the compose page after entering all the details.

Environment Details: QA/Staging

Build details: Provide the exact build number on which the defect is encountered
EX: ActiTime_1.01


Steps to Replicate/Reproduce:
1. Open browser and navigate to the URL (Ex: www.gmail.com)
2. Login with valid credentials
3. Navigate to "Compose" page by clicking the "Compose" link on the left top corner
4. Enter To, cc, Bcc, subject and body & then click on "Send" button

Expected Result:
1. The compose should be successful without any error
2. Appropriate confirmation message should display
3. The compose window should get close
4. The mail should reach the destination without any data loss.

Actual Result:
1. Getting "Nullpointer" exception upon clicking "Submit" button in the compose page after entering all the details.
2. Mail was not composed.

Additional Info:
The server error logs are attached.
The error screenshot is attached.


==================================
====Questions==============

1. Who will defines the severity & priority?
Ans: In our organization the QA will defines the severity & priority

2. To whom you will assign the defect?
Ans: In our organization we assign the defect to the respective developer.

3. How will you find the exact dev?
Ans:
in JIRA tool the dev name will be their against the reqt.
	OR
In standup meeting.



4. What if your defect is not addressed?
Ans: 
bring into the team notice in the standup meeting.
bring into Scrum Master notice.

5. Does the same QA should retest his defect?
Ans: Primarily the QA who logged the defect has to retest. But it can be done by others also.

5. Can someone modify the severity & priority of the defect?
Ans: Yes. But need to provide appropriate comments.

-------------------------------
Q: How to make sure the failure is a defect? OR Defect logging process?
Ans:
During test cases execution If QA finds any failure, then we should make sure the failure is a valid defect by following below steps:
1. Try to replicate/reproduce the issue with different test data.
2. Try to replicate/reproduce the issue in different environment OR computer.
   By performing above steps we can confirm whether the failure is a valid defect OR not. Once it is confirmed that the failure was a valid issue then follow the next step
3. Check for duplicate
 If no body has logged the issue, then go ahead & log the new defect
4. Log the defect in defect tracking tool with proper defect templates.

---------------------------------------
JIRA:
Here we will discuss about Defect Tracking tool JIRA:
JIRA components:

Product/Project: name of the project
Component: the module where you found the defect.
Version: The exact build number in which you found the defect.
Severity: How badly the defect is affected.
Priority: How fast it should be fixed.
Platform: in which OS you found the defect. Its mandatory for compatibility testing.
Browsers: in which browser you found the defect. Its mandatory for compatibility testing.
Target Milestone/Fix Version: in which build the defect has to be fixed
Status: NEW/Undefined/Unconfirmed/To Do
Assignee: The dev mail id to whom you are assigning the defect.
QA Contact: who logged the defect OR Point of contact for the defect.
Summary: Title for the defect	
Description: Defect template
Attachment: screenshot OR defect logs



Q: When QA is checking for duplicate issue, they found the same issue already logged with following status?
Case1: Found Same issue but the status is Closed
Ans: Log the new defect OR Reopen the defect

Case2: Found Same issue but the status is fixed
Ans: (a) Check the target milestone/Fix Version. If it is set to future build then no action by QA.
 (b) If the target milestone/Fix Version is set to the current build then QA should reopen the defect.

case3: Found Same issue but the status is Open
Ans: Just update the comment (It will be a duplicate defect)


Q: Project related Questions?
1. Give me min 3 examples for H. Severity & H. priority defects in your project?

2. Give me min 3 examples for H. Severity & L. priority defects in your project?

3. Give me min 3 examples for L. Severity & L. priority defects in your project?

4. Give me min 3 examples for L. Severity & H. priority defects in your project?

5. Give me examples of defects which you logged are directly affecting the business?

6. Brief, how did you justify with dev when they tell your defect is invalid?

---------------------------------------------
Defect Life Cycle: (Happy Path)
   When QA finds the failure, they make sure the failure is a valid defect. If its a valid defect, then log the defect against the dev in a defect tracking tool. The initial status of the defect will be NEW. While logging the defect assign the defect to respective dev who is owning that functionality.
   Dev goes through the defect & changes the defect status to IN-PROGRESS. Once they finds the root cause of the issue, it will be fixed and changes the defect status to FIXED with appropriate comments.
   
    The fix will be given to the QA in the next subsiquent build for retesting. During retesting If QA finds that the fix is working as expected, then close the defect by changing the defect status to CLOSED with appropriate comments.

Ex: "Validated the defect in the build <build Version> & found that the fix is working as expected. Hence closing the defect."

   During retesting If QA finds that the fix is not working as expected then reopen the defect by changing the defect status to REOPEN with appropriate comments.

EX: "Validated the defect in the build <build Version> & found that the issue still persist. Hence reopening the defect."

OR

"Validated the defect in the build <build Version> & found the following observations:
 The below points are working fine
1.
2.

where as the 
3.
4.
are not working as expected. Hence reopening the defect.


===========================================
Other invalid defect status:

(1) Invalid OR Not a defect OR Rejected.

Reason:
1. Dev/QA might be refering to old requirement Doc.
2. Dev/QA might have mis-understood the requirements.
3. QA might have logged wrong defect

During investigation dev will change the defect status to INVALID with appropriate comments.

QA Action:
1. Go through the Dev comments carefully. If you agreed to the dev comments then close the defect by changing the defect status to CLOSED with appropriate comments.
EX: "As per developer comments closing the defect".
  
   If QA not agreed to the dev comments then reopen the issue by changing the defect status to REOPEN with proper justifications/comments.

--------------------------------------
**(2) NOT REPRODUSIBLE:
Reason: The issue logged by the QA is working fine in Dev environment but not working in QA environment. Under such situation Dev will change the defect status to NOT REPRODUSIBLE with appropriate comments.

QA Actions:
1. Call the Dev to your desk, replicate the issue in QA environment by following the steps & show to him. 
2. If reprodusible, then Provide all the additional information which dev is asking for you for better understanding of the issue.
Ex: DB details, QA environment configuration details etc.

Note: If dev is in Onsite then discuss, replicate the issue & show them through WebEx OR team viewer etc.
-------------------------------------
(3) Duplicate:
    QA has logged one defect which was already logged by some other QA. Hence the newly logged defect becomes duplicate.
    During investigation dev will change the defect status to DUPLICATE with appropriate comments.
Ex: The defect id 1251 is the duplicate of the defect id 1200.

QA Actions:
1. QA should go through Dev comments. Open both the defects and compare them carefully. If QA agreed to the dev comments then close the defect by changing the defect status to CLOSED with appropriate comments.
EX: "As per dev comments closing the defect".

2. If QA feels both are unique then reopen the issue by changing the defect status to REOPEN with proper justifications/comments.
---------------------------------------
(4) Need Info:
Reason: The QA has not followed proper defect template OR has not provided proper details about the defect. Then dev will change the defect status to NEED INFO with proper comments.

QA Action: Act immediately, provide all the information what dev is asking for & then change the defect status to INFO PROVIDED.
----------------------------------------
**(5) Deffered:
    Unconditionally post-poning the defect is k.a., deferred.

Reason:
    The defect logged by the QA is not in the current scope OR 
   Dev team is very busy in fixing critical PROD issue. During such situation If QA logs the low severiy defect (which doesnot affect the business) then it will be deferred.
--------------------------------------------
(6) Enhancement:
   Any suggestions (nice to have) given by the Team members & which is not part of the requirements will be logged as Enhancements. It is also know as RFE (Request For Enhancement).

   This RFE will be given to customer for approval. If customer approves it, the RFE will converted to requirements. Otherwise it will be closed.
----------------------------------------
(7) Cannot fix OR Product limitations:
   Some time to fix the issues (which doesnot direct affect the business & moreover it has a work around for it) dev needs huge code change OR architectural changes. Which might affect the functionality of the whole product OR s/w. Under such situation we may mark the defect as CAN'T FIX.

--------------------------------

Q: When you find the defect:
Which point is highly recommended.
(a) Log it immediately in the tool
(b) Collect all the defects you found in the day & in the EOD log all of them.
(c) Dont log the issue in a tool. Just inform it in the stand up meeting

Ans: (a)


Q: Can anybody edit the defect?
Ans: Yes. Anybody can update/Edit the defect If required with proper comments. Automatically mail will be triggered to the members who are part of that defect.
