#How to Create Defects - Bug Reporting Guide

Creating defects is the first step in the defect management process. A well-documented defect helps developers understand the issue, reproduce it, and fix it efficiently. This guide covers all aspects of creating defects.

#Creating a New Defect

#To create a new defect:

1. Navigate to the Defects page (from project or workspace)
2. Click the Create Defect button in the header
3. Fill in the defect creation form
4. Add traceability links (optional)
5. Upload attachments (optional)
6. Click Create to save the defect

#Defect Form Fields

#Basic Information

Defect ID (Auto-generated):

• A unique identifier is automatically generated for the defect
• Format: DEF-001, DEF-002, etc.
• Cannot be changed after creation

Title (Required):

• Brief, descriptive summary of the defect
• Should clearly indicate what the issue is
• Example: “Login button does not respond on mobile devices”
• Maximum length: 255 characters

Description (Required):

• Detailed explanation of the defect
• Use rich text editor for formatting
• Include:
  • Steps to Reproduce: Step-by-step instructions
  • Expected Behavior: What should happen
  • Actual Behavior: What actually happens
  • Environment: Browser, OS, device, version
  • Additional Context: Any relevant information

Type:

• Bug: Functional issue or error
• Enhancement: Feature improvement request
• Task: General task or work item
• Default: Bug

#Priority and Severity

Priority: How urgent the defect is

• Critical: Blocks critical functionality, must be fixed immediately
• High: Important issue, should be fixed soon
• Medium: Moderate priority, fix when possible
• Low: Minor issue, can be deferred
• Default: Medium

Severity: How severe the impact is

• Blocker: Blocks all testing or critical functionality
• Critical: System crash, data loss, or security issue
• High: Major functionality broken
• Moderate: Some functionality affected
• Low: Minor issue, cosmetic problem
• Default: Moderate

Guidelines:

• Priority = Business impact (how urgent)
• Severity = Technical impact (how severe)
• Example: A typo might be Low severity but High priority if it’s customer-facing

#Assignment and Dates

Assignee (Optional):

• User assigned to fix the defect
• Can be assigned later if unknown
• Use “Assign to Me” to assign yourself

Reporter (Auto-filled):

• User creating the defect
• Automatically set to current user
• Cannot be changed

Due Date (Optional):

• Target date for defect resolution
• Use date picker to select date
• Helps prioritize and track deadlines

Status:

• Default: New
• Can be changed after creation

#Custom Fields

If your project has custom fields configured for defects, they will appear in the form:

Field Types:

• Text: Single-line text input
• Text Area: Multi-line text input
• Number: Numeric input
• Dropdown: Select from predefined options
• Checkbox: Boolean (yes/no)
• Date: Date picker

Fill in custom fields as needed. Required fields are marked with an asterisk (*).

#Traceability Links

Traceability links connect defects to related items:

#Linking Test Cases

To link a test case:

1. Click Add Test Case in the traceability section
2. Search or browse for test cases
3. Select test cases to link
4. Click Add to link them

Use Cases:

• Link to the test case that found the defect
• Link to test cases that verify the fix
• Link to related test cases

#Linking Requirements

To link a requirement:

1. Click Add Requirement in the traceability section
2. Search or browse for requirements
3. Select requirements to link
4. Click Add to link them

Use Cases:

• Link to the requirement that the defect affects
• Link to related requirements
• Track requirement coverage

#Linking Executions

To link a test run or release:

1. Click Add Execution in the traceability section
2. Select execution type (Test Run or Release)
3. Search or browse for executions
4. Select executions to link
5. Click Add to link them

Use Cases:

• Link to the test run where the defect was found
• Link to releases affected by the defect
• Track defect discovery context

Note: You can link multiple items of each type. Links can be added or removed after creation.

#Attachments

#Uploading Files

To upload attachments:

1. Click Upload Files or drag and drop files
2. Select files from your computer
3. Files are uploaded and attached to the defect

Supported File Types:

• Images: PNG, JPG, GIF, SVG
• Documents: PDF, DOC, DOCX
• Spreadsheets: XLS, XLSX
• Text files: TXT, LOG
• Other: ZIP, etc.

File Size Limits:

• Maximum file size: Check your project settings
• Multiple files can be attached

#Best Practices for Attachments

1. Screenshots: Include screenshots showing the issue
2. Error Logs: Attach error logs or stack traces
3. Videos: Record screen videos for complex issues
4. Test Data: Include sample data files if relevant
5. Configuration: Attach configuration files if needed

#Defect Creation Workflow

#Step-by-Step Process

1. Identify the Issue: Recognize that a defect exists
2. Gather Information: Collect details about the issue
3. Create Defect: Fill in the defect form
4. Add Details: Provide comprehensive description
5. Set Priority/Severity: Assess urgency and impact
6. Link Related Items: Connect to test cases, requirements, executions
7. Attach Files: Upload screenshots, logs, or other files
8. Review: Review all information before creating
9. Create: Click Create to save the defect

#Form Validation

The form validates:

• Title: Required, cannot be empty
• Description: Required, cannot be empty
• Custom Fields: Required custom fields must be filled

Errors are displayed inline, and the form cannot be submitted until all required fields are valid.

#Tips for Effective Defect Reporting

#Writing Clear Titles

• Be Specific: “Login button not working” vs “Button issue”
• Include Context: “Mobile login button not responding” vs “Login button issue”
• Avoid Ambiguity: Use clear, unambiguous language
• Keep It Concise: Aim for 50-80 characters

#Writing Detailed Descriptions

Structure:

1. Summary: One-sentence overview
2. Steps to Reproduce: Numbered list
3. Expected Behavior: What should happen
4. Actual Behavior: What actually happens
5. Environment: Browser, OS, device, version
6. Frequency: Always, sometimes, once
7. Workaround: If any exists

Example:

Summary: The login button does not respond when clicked on mobile devices.

Steps to Reproduce:
1. Open the application on a mobile device
2. Navigate to the login page
3. Enter credentials
4. Click the "Login" button

Expected Behavior:
The user should be logged in and redirected to the dashboard.

Actual Behavior:
Nothing happens when the button is clicked. No error message is displayed.

Environment:
- Device: iPhone 12
- OS: iOS 15.0
- Browser: Safari 15.0
- App Version: 2.1.0

Frequency: Always

Workaround: None

#Setting Priority and Severity

Priority Guidelines:

• Critical: Blocks release or critical business function
• High: Affects important features, impacts users
• Medium: Affects some users or features
• Low: Minor issue, cosmetic problem

Severity Guidelines:

• Blocker: Cannot proceed with testing or use
• Critical: System crash, data loss, security breach
• High: Major functionality broken
• Moderate: Some functionality affected
• Low: Minor issue, cosmetic

Combination Examples:

• Critical Priority + Blocker Severity: Must fix immediately
• High Priority + High Severity: Fix soon, major impact
• Low Priority + Low Severity: Can defer, minor issue

#Using Traceability

When to Link:

• Test Cases: Always link to the test case that found the defect
• Requirements: Link if the defect affects a requirement
• Executions: Link to the test run or release where found

Benefits:

• Track defect discovery context
• Understand test coverage
• Monitor requirement quality
• Analyze defect trends

#Defect Templates

Consider creating defect templates for common issues:

UI Defect Template:

• Title: [Component] [Issue] on [Page/Screen]
• Description: Include screenshot, browser/device info
• Priority: Based on visibility
• Severity: Usually Low to Moderate

Functional Defect Template:

• Title: [Feature] [Issue] when [Action]
• Description: Detailed steps, expected vs actual
• Priority: Based on feature importance
• Severity: Based on impact

Performance Defect Template:

• Title: [Feature/Page] [Performance Issue]
• Description: Include performance metrics, load times
• Priority: Based on user impact
• Severity: Usually High or Critical

#Common Mistakes to Avoid

1. Vague Titles: “Bug” or “Issue” are not helpful
2. Missing Steps: Don’t assume developers know how to reproduce
3. No Screenshots: Visual evidence is crucial
4. Wrong Priority/Severity: Be realistic about impact
5. Missing Environment: Always include environment details
6. No Traceability: Link to related items for context
7. Incomplete Description: Provide all relevant information

#After Creating a Defect

Once created, the defect:

• Appears in the defects list
• Can be assigned to a developer
• Can be updated with additional information
• Can be linked to other items
• Can be commented on by team members
• Tracks its history automatically

#Permissions

To create defects, you need:

• Create Defects permission at the project level
• Access to the project or workspace

Contact your project administrator if you cannot create defects.

#Next Steps

• Learn about Tracking Defects to manage defect lifecycle
• Explore Defect Management Overview for comprehensive information
• Check out Test Runs to link defects to test executions
• Review Requirements to link defects to requirements