Archives: Helps

Bug Resolution in Orangescrum Cloud represents the final status or action taken on a reported issue.

It helps your team record how each bug was handled — whether it was fixed, rejected, duplicated, or could not be reproduced.

This setting brings clarity to your QA cycle and enables better reporting on software quality and resolution trends.

Example: A bug marked as Fixed indicates it has been resolved, while Duplicate shows that a similar issue already exists in the tracker.

Why Use Bug Resolution

• Clarify outcomes: Record the final result of every issue.
• Enhance reporting: Filter and analyze resolved, duplicate, or invalid bugs.
• Track QA efficiency: Understand how many bugs are successfully fixed versus deferred.
• Reduce confusion: Maintain transparency on why an issue was closed.

Accessing Bug Resolution Settings

1. Navigate to Settings → Bug Settings → Resolution.
2. You’ll see a predefined list such as Fixed, Duplicate, Will Not Fix, Can Not Reproduce, Not an Issue, and N/A.
3. You can add, edit, or remove resolutions to align with your internal QA process.

Common Bug Resolution Types

Resolution	Description
Fixed	The bug has been successfully corrected and verified.
Duplicate	The bug is already reported in another ticket.
Will Not Fix	The issue is acknowledged but won’t be fixed (low impact or outside scope).
Can Not Reproduce	QA could not replicate the bug based on current data.
Not an Issue	The reported behavior is intentional or not a defect.
N/A (Not Applicable)	The bug report was invalid or no longer relevant.

Tip: Standardizing resolutions helps your reporting stay accurate across multiple projects and releases.

Adding a New Bug Resolution

1. Click + New Bug Resolution (top-right corner).
2. Enter a clear, descriptive Resolution Name (e.g., Deferred, Won’t Fix in Current Version).
3. Click Add to save it.
4. The new option will be available for selection when updating a bug’s status.

Editing or Deleting Resolutions

• To Edit, click the icon next to a resolution.
• To Delete, click the icon to remove outdated options.

Note: Removing a resolution does not delete existing bugs but unlinks that resolution type from future records.

Bug Origin in Orangescrum Cloud helps teams trace where in the project lifecycle a defect was introduced — such as during Requirements, Design, or Development.

By recording the origin of bugs, project managers and QA teams can analyze process gaps, improve quality controls, and reduce recurrence in future cycles.

Example: If a defect is traced back to the Requirements phase, it means the issue originated from unclear specifications rather than poor coding.

Why Use Bug Origin

• Improve root cause analysis: Identify the source of recurring defects.
• Enhance team accountability: Pinpoint which stage needs better QA checks.
• Improve quality metrics: Track bug density by lifecycle phase.
• Strengthen prevention strategies: Focus on process improvements early in the cycle.

Accessing Bug Origin Settings

1. Go to Settings → Bug Settings → Origin.
2. You’ll see default origins like Requirements, Design, and Development.
3. Add or edit these to match your internal project lifecycle.

How It Works

Each bug logged in Orangescrum can be tagged with its Origin.

This makes it easy to track not just when an issue occurred but where it started.

Field	Description	Example
Bug Origin	The phase where the defect was introduced.	Requirements, Design, Development
Usage	Selected during bug reporting or analysis.	Helps QA trace the source of errors

Tip: Combine “Origin” with “Root Cause” and “Phase” fields to conduct deeper defect trend analysis.

Adding a New Bug Origin

1. Click + New Bug Origin (top-right).
2. Enter the Origin Name — e.g., Testing, Deployment, Documentation.
3. Click Add to save.
4. The new origin will now appear in your selection list when creating or updating bugs.

Editing or Deleting Origins

• Click Edit to rename an existing origin.
• Click Delete to remove outdated or unused origins.

Note: Removing a Bug Origin unlinks it from existing bugs but doesn’t delete those issues.

Affect Version in Orangescrum Cloud helps you record where a defect was first found — the specific product or project version affected by the issue.

It’s a vital part of release management that ensures bugs are traced to their origin and verified properly during regression testing.

Example: If a bug appeared in V30 but was fixed in V31, the Affect Version indicates where the problem originated, helping QA confirm it no longer exists in newer builds.

Why Use Affect Version

• Trace defect origin: Identify which release introduced the issue.
• Support regression testing: Test fixes against the same version the bug appeared in.
• Improve reporting: View defect trends per release.
• Enhance visibility: Understand how product updates affect system stability.

Accessing Affect Version Settings

1. Navigate to Settings → Bug Settings → Affect Version.
2. You’ll see a list of configured versions (e.g., V30).
3. Add, edit, or remove versions as your project evolves.

How It Works

When a bug is logged, the reporter selects the Affect Version — indicating which release was impacted.

Later, the Fix Version field can be used to mark the version where it was resolved.

Field	Description	Example
Affect Version	The version where the issue was found.	V30
Fix Version	The version where the issue was fixed.	V31

Tip: Keeping both fields updated provides full visibility into bug lifecycles across versions.

Adding a New Affect Version

1. Click + New Affect Version (top-right).
2. Enter a clear Version Name (e.g., V30, Release 2.0).
3. Click Add to save it.
4. The version becomes selectable in bug reports.

Editing or Deleting Versions

• To Edit, click the icon next to the version.
• To Delete, click the icon to remove unused versions.

Note: Deleting a version unlinks it from bugs but does not delete the bugs themselves.

Track and manage bug fixes across releases with clarity. The Fix Version feature in Orangescrum Cloud helps teams track which release or version a bug or issue was fixed in.

It ensures product stability and provides a clear historical reference for every issue — making it easier for QA teams, developers, and release managers to validate fixes and plan version rollouts efficiently.

💡 Fix Versions are primarily used in bug tracking and release management workflows.

Where to Find Fix Version

You can find the Fix Version option under:

Settings → Bug Settings → Fix Version

Here, Admins and Project Managers can:

• Add new Fix Versions
• Edit existing Fix Versions
• Delete or deactivate unused Fix Versions

How to Create a New Fix Version

1. Go to Settings → Bug Settings → Fix Version
2. Click + New Fix Version (top-right corner)
3. Enter a version name (e.g., v1.1.0 or Sprint_15_Fix)
4. Click Save

Your new Fix Version will appear in the list and can be assigned to any bug or issue during or after resolution.

Use consistent naming (like “v1.0.1”, “Patch_Q4_2024”) to simplify release tracking.

Editing or Deleting a Fix Version

• To edit, click the icon beside the version name.
• To delete, click the trash icon.

⚠️ Deleting a Fix Version will remove it from any associated bugs, so use with caution.

Using Fix Version in Bug Tracking

When creating or updating a bug, you can assign a Fix Version to indicate the version or release where the issue will be (or has been) resolved.

Example:

• Bug: “Login page throws 500 error”
• Fix Version: v2.3.1
• Status: Resolved

This helps QA testers verify the bug in the specific build or deployment.

🔍 QA teams can filter bugs by Fix Version to focus on regression and validation testing.

Why Fix Version Matters

Benefit	Description
Release Tracking	Know which issues were fixed in each version or patch.
Quality Assurance	Test teams can validate fixes before release.
Change Log Management	Automatically generate fixed summaries for release notes.
Historical Audit	Keep a clear history of what was fixed, when, and in which version.

Best Practices

✅ Align Fix Versions with your release cycle — e.g., Sprint numbers, product versions, or deployment dates.
✅ Use descriptive version names — to easily match versions with builds or repositories.
✅ Update regularly — close out old versions and archive completed ones to maintain clarity.
✅ Combine with Affect Version — to see where the issue appeared vs. where it was fixed.

Example Use Case

Bug ID	Summary	Affect Version	Fix Version	Status
#1021	Login error on mobile	v2.2	v2.3	Resolved
#1035	Slow loading dashboard	v2.3	v2.4	Fixed
#1040	Email notifications not triggering	v2.1	v2.3	Closed

🧾 This table gives teams a full audit trail across defects, fixes, and releases.

💡 Related Bug Settings

Setting	Description
Affect Version	Indicates which version the issue was found in.
Root Cause	Defines the underlying reason behind the issue.
Severity	Measures the impact level of the bug.
Phase	Shows the stage where the bug was identified or fixed.

Bug Root Cause in Orangescrum Cloud helps teams record and analyze the fundamental reason behind a bug’s occurrence — not just its symptoms.

By identifying why a defect was introduced (e.g., missing validation, unclear requirements, or configuration errors), teams can implement corrective actions to prevent similar issues in future releases.

Example: If a bug’s root cause is “Requirement Misinterpretation,” the corrective action could be improving requirement review and clarification meetings before development begins.

Why Use Root Cause Analysis

• Discover patterns: Identify recurring causes of defects across modules or teams.
• Improve processes: Strengthen QA, design, and development practices based on insights.
• Enhance reporting: Classify bugs by cause to track and reduce defect leakage.
• Prevent recurrence: Turn reactive debugging into proactive quality improvement.

Accessing Bug Root Cause Settings

1. Go to Settings → Bug Settings → Root Cause.
2. The list shows all existing root causes configured in your workspace.
3. You can add new ones or edit/remove existing items at any time.

Common Examples of Root Causes

Root Cause	Description	Example
Requirement Gap	Missing or misunderstood requirements.	Feature logic unclear in PRD.
Design Flaw	Poor architecture or design approach.	Missing error handling flow.
Coding Error	Incorrect logic or syntax.	Null pointer exception in Java.
Integration Issue	Misaligned APIs or incompatible modules.	Data mismatch between modules.
Testing Coverage Gap	Missed edge cases or incomplete testing.	Feature passed unit tests but failed in regression.
Configuration Error	Incorrect environment or deployment setup.	Wrong API keys in staging environment.

Tip: You can customize root cause categories based on your industry or workflow — for instance, add Data Error, Third-Party Dependency, or Human Error as needed.

Adding a New Root Cause

1. Click + New Root Cause (top-right corner).
2. Enter a descriptive Root Cause Name (e.g., Requirement Gap, Configuration Error).
3. Click Add to save it.
4. The new cause will appear in your list and can be selected during bug reporting or analysis.

Editing or Deleting a Root Cause

• To Edit, click the icon beside an existing cause.
• To Delete, click the icon if the cause is no longer relevant.
• Deletion will unassign the cause from existing issues but keep the records intact.

Bug Root Cause in Orangescrum Cloud transforms your defect tracking into a learning process — helping your teams identify, analyze, and eliminate the real reasons behind recurring issues.

Bug Phase in Orangescrum Cloud allows you to define at which stage of the project a defect was identified — such as during Requirements Gathering, Design, Development, Testing, or Deployment.

This helps project managers and QA teams analyze the origin of issues, identify process bottlenecks, and improve quality control at every phase of the software development lifecycle (SDLC).

Example: If multiple issues are logged during the “Design” phase, it indicates the need for stronger design review or validation steps.

Why Define Bug Phases

• Pinpoint issue origins — know exactly when and where bugs are introduced.
• Improve process control — strengthen quality assurance at weak stages.
• Generate better analytics — understand trends and prevent future defects.
• Enhance collaboration — give visibility to both development and QA teams on recurring phase-level issues.

Accessing Bug Phase Settings

1. Navigate to Settings → Bug Settings → Phase.
2. You’ll see a list of existing default phases such as Requirements, Design, and Development.
3. You can add, edit, or remove phases based on your workflow or development process.

Default Bug Phases

Phase	Description	Example
Requirements	Bugs introduced due to unclear or incomplete requirements.	Missing acceptance criteria, ambiguous scope.
Design	Defects identified in UI/UX or architectural design.	Incorrect layout, poor navigation flow.
Development	Code-related bugs found during implementation or testing.	Logic errors, broken API calls, data mismatch.
Testing (custom)	Issues detected during QA or user acceptance testing.	Validation errors, regression bugs.
Deployment (custom)	Problems occurring after release or deployment.	Configuration errors, environment issues.

Note: You can customize these phases to match your specific SDLC or Agile workflow.

Adding a New Bug Phase

1. Click + New Bug Phase (top-right corner).
2. Enter a clear and descriptive Phase Name (e.g., Testing, UAT, Production).
3. Click Add to save it.
4. The new phase will appear in your list and be available during bug reporting.

Editing or Deleting Phases

• To Edit, click the icon beside a phase name and update the text.
• To Delete, click the icon to remove unused phases.
• Deleting a phase will unassign it from existing issues, but will not delete the issues themselves.

Tip: Always align your Bug Phases with your project’s actual delivery workflow — for example, Agile sprints or Waterfall milestones.