Bug Attributes (in BTS)
Bug Attributes in a Bug Tracking System (BTS) are specific properties or metadata associated with a reported bug, used to describe, categorize, and manage it throughout its lifecycle. These attributes help in organizing, prioritizing, and tracking bugs effectively, enabling better collaboration among development, testing, and management teams. Properly defined bug attributes ensure clear communication and systematic resolution of defects.
Key Attributes of a Bug in a BTS:
- Bug ID: a unique identifier automatically assigned by the system to distinguish the bug from others.
- Title/Summary: a concise description of the bug, highlighting the main issue (e.g., “Login page crashes on invalid input”).
- Description: detailed information about the bug, including:
- Steps to reproduce.
- Expected vs. actual behavior.
- Additional observations or context.
- Severity: indicates the impact of the bug on the system’s functionality. Common levels:
- Critical: blocks core functionality or causes a system crash.
- Major: affects significant functionality but has a workaround.
- Minor: impacts non-essential features.
- Trivial: cosmetic or negligible issues.
- Priority: determines the urgency of fixing the bug based on business or project needs. Typical levels:
- High: must be fixed immediately.
- Medium: should be addressed soon.
- Low: can be deferred.
- Status: tracks the current state of the bug in its lifecycle. Common statuses include:
- New: recently reported.
- Assigned: assigned to a developer for resolution.
- In Progress: currently being worked on.
- Fixed: the issue is resolved in code.
- Verified: the fix has been tested and confirmed.
- Closed: the bug is resolved and no longer reproducible.
- Reopened: the bug persists or reoccurs.
- Assigned To: the name of the developer or team responsible for fixing the bug.
- Reported By: the individual who identified and logged the bug in the system.
- Bug Type: categorizes the nature of the bug, such as:
- Functional: related to system functionality.
- Performance: affects system speed or responsiveness.
- UI/UX: impacts user interface or design.
- Security: creates vulnerabilities.
- Compatibility: issues on specific platforms or configurations.
- Reproducibility: indicates whether the bug can be consistently reproduced. Typical values:
- Always: occurs every time.
- Intermittent: occurs under certain conditions.
- Cannot Reproduce: not consistently observable.
- Environment: details about the environment where the bug was found, including:
- Operating system.
- Browser/version.
- Hardware specifications.
- Test environment configuration.
- Version: specifies the software version or build number where the bug was detected.
- Attachments: additional files such as screenshots, log files, videos, or error reports that provide evidence or context for the bug.
- Module/Component: indicates the specific area or feature of the application affected by the bug.
- Steps to Reproduce: a step-by-step guide to recreating the bug, enabling developers and testers to verify the issue.
- Resolution: describes how the bug was resolved. Common resolutions include:
- Fixed: code changes resolved the issue.
- Won’t Fix: the issue is not deemed critical or relevant.
- Duplicate: the bug is a duplicate of another reported issue.
- Invalid: the issue is not a bug.
- Deferred: fix is postponed for future releases.
- Date Fields:
- Reported Date: when the bug was logged.
- Resolved Date: when the bug was fixed.
- Closed Date: when the bug was confirmed resolved and closed.
- Comments/Notes: a section for testers, developers, or stakeholders to provide additional observations, updates, or discussions about the bug.
