0% found this document useful (0 votes)
50 views

Jira - Defect Creation Concept

Uploaded by

Priya Solapure
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
50 views

Jira - Defect Creation Concept

Uploaded by

Priya Solapure
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

Defect

When the application is not working as per the requirement is knows as defects. It is
specified as the aberration from the actual and expected result of the application or
software.

Defect Life Cycle

The number of states that a defect goes through varies from project to project.
Below lifecycle diagram, covers all possible states
 New: When a new defect is logged and posted for the first time. It is
assigned a status as NEW.
 Assigned: Once the bug is posted by the tester, the lead of the tester
approves the bug and assigns the bug to the developer team
 Open: The developer starts analyzing and works on the defect fix
 Fixed: When a developer makes a necessary code change and verifies the
change, he or she can make bug status as “Fixed.”
 Pending retest: Once the defect is fixed the developer gives a particular
code for retesting the code to the tester. Since the software testing
remains pending from the testers end, the status assigned is “pending
retest.”
 Retest: Tester does the retesting of the code at this stage to check
whether the defect is fixed by the developer or not and changes the status
to “Re-test.”
 Verified: The tester re-tests the bug after it got fixed by the developer. If
there is no bug detected in the software, then the bug is fixed and the
status assigned is “verified.”
 Reopen: If the bug persists even after the developer has fixed the bug, the
tester changes the status to “reopened”. Once again the bug goes through
the life cycle.
 Closed: If the bug is no longer exists then tester assigns the status
“Closed.”
 Duplicate: If the defect is repeated twice or the defect corresponds to the
same concept of the bug, the status is changed to “duplicate.”
 Rejected: If the developer feels the defect is not a genuine defect then it
changes the defect to “rejected.”
 Deferred: If the present bug is not of a prime priority and if it is expected
to get fixed in the next release, then status “Deferred” is assigned to such
bugs
 Not a bug: If it does not affect the functionality of the application then the
status assigned to a bug is “Not a bug”.

Defect Creation in JIRA

Defect reporting needs the following information recorded for every


issue:
 Defect ID
 Defect title
 Defect description (steps to reproduce)
 Environment information
 Screenshot(attachment)
 Priority and Severity
 Component/Label
 Assign it to someone
 Status- All the statuses in the bug life cycle
All the options are available to be able to create a defect effectively.

Creation of Defect

Click on Create button

Select Project

Select Issue type as Bug

Enter the Summary of that Defect


Summary means the title of the issue. The title should be as unique and precise as possible
so that by looking at the title itself, the issue can be understood.

Components

Components are subsections of a project. They are used to group issues within a project into smaller sets.
Note: In Company, component is created by project manager or lead. You need to select component is
dropdown list

Description:

-Typically Description contains Steps to Reproduce of the issue Actual Result, Expected Result

Reporter

This filed is auto-populated by Jira with the name of the logged in user.

Fix Versions

Name of the version in which the issue/enhancement request will be delivered. This value is
typically filled by the product owner in co-ordination with the scrum master in an agile scrum
environment.

Priority
Defect categorization help the software developers to prioritize their tasks. That means that
this kind of priority helps the developers in fixing those defects first that are highly crucial.

Labels:

This field is entered with the texts which will help in categorizing issues.

Environment:

This is an optional field and the test environment is specified here.


Attachment:

Supporting images for the issue being created. The user can simply drag and drop images or
copy and paste

Affect versions

For a ‘bug’ type of issue, the product version should be entered here For Example 5.6, 5.7 etc.

But not need to enter Affect versions

Linked Issues:
Other relevant issues can be linked to the new issue by choosing a proper value from this drop-
down.
Means for example test case is failed link that test case into the defect.

Assignee:
It is the name of the user who will be working on the issue. For instance, in the case of a bug, it
will be the name of the developer who will fix the issue.
Epic Link:

Choose the relevant link of the epic.

Sprint:

Name of the sprint is selected here,

Click on Create button


Defect is created

Click on View Issue

Click on … dots

Click on See the old view


AM-1 is the ID of that defect

In case if you are having ID. You can search here

Comments and collaboration with the Dev Team


Suppose here Prachi is developer. She did 3 things
1)put the comment ex please retest
2)changed defect status as pending retest
3)Assigned defect to the tester for retest purpose

In that case Tester role


Retest the defect
1) Put screenshot
2) Put comment
3) Changed status as Resolved/Done/Closed
Another Sample Defect
In case If you are doing testing and URL is not loaded
Need to raise defect

Some basics
[Note: In every company defect life cycle workflow diagram is different]
When developer fix the defect

Developer do

1) He give the comment. Ex. Please Retest

2) Changed the status as - pending retest/Retest

3) Change the assignee name as- Tester name


When developer assigned defect to the tester

Tester needs to retest the defect

-that case Tester do

1) Attach the screenshot [Use snipping tool ]

2) Give the comment. Ex. Issue has been resolved. PFA.

3) Change the status as - Done/closed

When developer assigned the defect to the tester

But its not correctly working

-that case Tester do

1) Change the status - Retest Fail

2) Attach the screenshot

3) Change the assignee name - developer Name

4) Give the comment - Not able to login URL hence reassigning the defect. PFA.

In Case defect is closed and again find same issue

-That case tester do

1) Change the status as Reopen

2) Attach the screenshot

3) Give the comment. Eg. Same issue persist again

4) Change the assignee name as- developer name

Note: some basics

For Taking Screenshot

You can use

1) Prt sc button

2) Snipping Tool – by using snipping easily highlight error message

3) Lightshot app – this app allows you to select any area on your desktop and take its
screenshot with 2 button-clicks. By using this app you can easily add rectangle box of error
message.
For taking screenshot using lightshop app, use prt sc button. If you want to back press esc
button

4) Paint

Defects can be exported into Word, XML, and printable formats


This supports better portability of your defect data, especially useful if you want to share your
defect data with people who are non-JIRA users.

Cloning an Issue
If you ever need to create a duplicate of an issue, there’s no need to do everything manually. Cloning enables
you to duplicate an issue within the same project, copying over most information from an issue like the
Summary and Description fields and more.

Cloned issues exist as a separate entity to the original issue. Their only connection is that, upon cloning, the
two issues are linked — though you can unlink them any time.

In the cloning process, some information from the original issue isn’t automatically cloned but can be
included:
 Attachments
 Subtasks
 Links
 Custom fields (if they’re set up to be cloned).

To clone an issue:

1. Open an issue.
2. Select ··· > Clone.
3. Edit the Summary.
4. Choose what to Include (if any).
5. Select Clone.
How to create defect Filter in JIRA
In company don’t need to do this activity. But if you want to create defect filter. You can
create it.

Why is filter used in Jira?


To quickly find an issue or set of issues in your project.
 By using Defect filter, you can see how many defect in your project.
1) Click on Issues left side
2) Type the query -

project = AM AND issuetype = Bug

3) Click on search button

Defect list is shown

4) Click on Save Filter


5) Give the name of filter
6) Click on Save button
7) Click on view filter
8) Save the URL -
Screenshots

Click on issues

Click on JQL

Type Query
Click on Search

Click on Save Filter


Give Name of Filter

Click on Save button

Click on View Filter


Save defect Filter URL

https://fusion12023.atlassian.net/issues/?filter=10004

Interview Question

1. What is Workflow
Answer - Workflow is defined as a movement of the bug/issue through various stages during its
life-cycle
Here explain Defect Life Cycle

2. What is a duplicate defect?


Answer - Duplicate defect- The defects which is related or same or similar as current defects,
these type of defects called Duplicate defect 
Ex. Paytm- Recharge module – All mobile no. not accepted tester has raised the defects 
Again Airtel, BSNL, VI mobile no is not accepted- defect- Duplicate defect

3. What is your approaches when developer will not accepting the defects?

Answer-

In my project, when we got defects then we will create / log into JIRA

 In create defects we will add attachment/ Screenshot but still developer is not accepting

 Then we will take call with developer & share the screen and show case to him

 But still developer is not accepting- We will go to another Tester system & check the defects

 If defects is present then we will inform to inform

 But still developer is not accepting- We will inform to Test lead & same we will mail to PM, Test
lead, developer, designer & all tester

 In daily stand up we will raised these issue.


OR

--in this situation what you can do is first verify that defect/bug is valid or not ? If it is valid then try
to reproduce in different system and send screenshot, proper defect report to developer. Now even
after this developer is not accepting then you can send email to respective developer regarding issue
and cc to you test lead.

If Test lead is also not taking it seriously or not accepting then you can escalate this issue to Test
Manager. Even though if they are not accepting then take final call with Business Analyst or Product
Owner. B.A/P.O is the person who closely interact with client/business, so you can check with him. If
B.A is telling this is not a bug then you can write a B.A comment in JIRA/Test Case and close it.

If B.A is accepting this as a defect/bug then send email and inform why this is a bug to respective
developer, cc to development lead, test lead, test manager, B.A/P.O

4. How many defects your are creating/lock per day/ Per US?
Answer- It is totally depends on user story
 If US is complex & developer is not done coding properly then I found more defects
 If US is simple & developer is done coding properly then I found less defects
 An average, I am creating/lock 3 to 4 or 4 to 5 test cases per day/ Per US

5. How many defect you are lock per day


Exact we can’t say, it totally depends on which testing or user story you are testing.  Yes, an
average, I am locking 3 to 4 defect per day

6. What is Bug leakage


Defect/ Bug which is missed from SIT and found in UAT or Product  Occurred due to –
Functionality is not understand, Deployment is not proper, Environments problem of UAT or
Product

7. What are challenges you have in your whole carrier/ last Project?
Answer- Lack of knowledge about project/ domain
 Lack of test data in testing
 Lack of resources in testing-
 Lack of development process –
 Lack of time or deployment
 Lack communication in between BA, developer
 Lack of budget in project

8. Which test cases will be considering as good test cases


It should be simple
 It should be easy to understand
 It should be specific
 It should cover all the functionality
 It should be more precise
9. What are parameters or field are present while created defects
Summary* – Short Description
Description* - Step to re-product a defects
Assigned to* – To developer name
Created by* – Tester name
Priority
Defected environment
Status*
Detected date*- System generated date
Screenshot/ Attachment

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy