Unit 2: Bug Reporting - Subjective Questions

A software bug report is a structured record that describes a defect, failure, or unexpected behavior observed in a software product. It provides developers and other stakeholders with the information needed to understand, reproduce, prioritize, and resolve the defect.

The main objectives of an effective bug report are:

• Communicate the problem clearly: Explain what went wrong without ambiguity.
• Enable reproduction: Provide exact steps, test data, and environment details required to reproduce the defect.
• Show expected and actual behavior: State what the system should have done and what it actually did.
• Support prioritization: Describe the severity, frequency, and business impact of the defect.
• Assist diagnosis: Include logs, screenshots, error messages, and other evidence.
• Prevent duplication: Give the report a precise and searchable title.
• Track resolution: Create a record that can move through assignment, fixing, verification, and closure.

A bug report is more likely to result in a fix when it has the following characteristics:

• Clear title: The summary identifies the affected feature and visible failure.
• Reproducibility: The report contains numbered, minimal, and unambiguous reproduction steps.
• Specificity: It identifies the product version, operating system, browser, device, configuration, and test data.
• Expected versus actual results: The difference between intended and observed behavior is explicitly stated.
• Objective language: The report focuses on facts and avoids blame, assumptions, and emotional wording.
• Useful evidence: Relevant screenshots, videos, logs, stack traces, and crash dumps are attached.
• Correct classification: Severity, priority, component, and defect type are selected appropriately.
• Conciseness: Irrelevant background information is removed while all necessary diagnostic details are retained.
• Searchability: Important error messages and feature names appear in the summary and description.

Such a report reduces investigation effort and allows the development team to act without repeatedly asking the reporter for clarification.

Bug isolation is the process of reducing a failure to the smallest set of conditions that causes it. A systematic procedure is:

1. Confirm the failure: Repeat the original test and verify that the behavior is genuinely incorrect.
2. Record the environment: Note the build, platform, configuration, permissions, test data, and external dependencies.
3. Reduce the steps: Remove one action at a time and check whether the bug still occurs.
4. Simplify the data: Replace complex input with smaller or more controlled data.
5. Vary one factor at a time: Change the browser, operating system, user account, network, configuration, or application version independently.
6. Identify boundaries: Determine the first version, input size, state, or operation at which the failure appears.
7. Separate components: Use stubs, logs, APIs, or direct database checks to determine which subsystem is responsible.
8. Compare working and failing cases: Identify the smallest meaningful difference between them.
9. Document the minimal case: Record the shortest reliable sequence and all required preconditions.

Effective isolation narrows the probable cause, improves reproducibility, and reduces debugging time.

To reproduce a bug means to make the same failure occur again by following a known sequence of actions under defined conditions.

Reproducibility is important because it:

• Confirms that the observation is a genuine defect rather than a misunderstanding or one-time environmental event.
• Gives developers a reliable starting point for investigation.
• Allows testers to verify whether a proposed fix works.
• Helps identify the exact conditions and component responsible for the failure.
• Reduces unnecessary communication between testers and developers.

An intermittent bug should still be reported. The report should include:

• The number of failures compared with the number of attempts.
• Timestamps and the order of events.
• System load

A software bug report is a structured description of a defect, failure, or unexpected behavior found in a software product. It provides developers with the information needed to reproduce, analyze, prioritize, and correct the problem.

An effective bug report should be:

• Clear: Use precise and unambiguous language.
• Reproducible: Provide complete steps for reproducing the defect.
• Specific: Describe one distinct problem rather than combining multiple issues.
• Complete: Include environment, input data, expected result, and actual result.
• Objective: Report observable facts without assumptions or blame.
• Traceable: Include a unique identifier, version, date, and reporter details.
• Supported by evidence: Attach screenshots, logs, videos, stack traces, or test data when relevant.

A good report reduces investigation time and increases the probability that the bug will be fixed correctly.

A tester can improve the chances of getting a bug fixed by presenting reliable evidence and explaining the defect's impact.

• Write a short and descriptive title that identifies the failure.
• Report one bug per report so that each issue can be tracked independently.
• Provide exact, numbered steps to reproduce.
• Clearly distinguish the expected result from the actual result.
• Specify the software version, operating system, browser, device, configuration, and test data.
• Attach relevant evidence such as logs, screenshots, videos, crash dumps, and stack traces.
• State the bug's effect on users, business operations, security, or data.
• Assign a reasonable severity and avoid exaggerating the problem.
• Search for existing reports to prevent duplicates.
• Cooperate with developers by answering questions and retesting proposed fixes.

A factual, concise, and reproducible report allows the development team to evaluate and correct the defect efficiently.

Bug isolation is the process of narrowing a failure to the smallest set of conditions, inputs, components, or actions responsible for producing it.

A systematic isolation procedure includes:

1. Confirm the failure: Repeat the original test and verify that the unexpected behavior is genuine.
2. Control the environment: Record the software build, hardware, operating system, configuration, permissions, and network state.
3. Reduce the test case: Remove unnecessary actions, data, and configuration settings while checking whether the failure remains.
4. Vary one factor at a time: Change a single input or condition and compare the result.
5. Identify boundaries: Test values around the failing input, such as minimum, maximum, empty, and invalid values.
6. Compare environments: Try another browser, device, account, database, or software version.
7. Inspect evidence: Examine logs, error messages, stack traces, requests, and database changes.
8. Document the minimal case: Record the shortest reliable sequence that triggers the defect.

Isolation helps developers locate the faulty subsystem and prevents unrelated conditions from obscuring the root cause.

Reproducing a bug means causing the same failure again under known conditions. Reproducibility confirms that the problem is real and gives developers a controlled way to investigate it.

It is important because it:

• Verifies the tester's observation.
• Helps identify the conditions that trigger the failure.
• Allows developers to debug the relevant execution path.
• Enables testers to confirm that a later fix is effective.
• Supports the creation of a regression test.

A reproducible report should include:

• Product name, build number, and version.
• Operating system, browser, device, hardware, and configuration.
• Preconditions such as account state, permissions, and stored data.
• Exact numbered steps in the order performed.
• Input values, files, commands, or test data.
• Expected and actual outcomes.
• Frequency of occurrence, such as 5 out of 5 attempts.
• Logs, timestamps, screenshots, videos, or stack traces.
• Any cleanup or reset required before repeating the test.

If a failure is intermittent, the report should state that fact and record all known patterns instead of claiming that it is consistently reproducible.

Severity describes how seriously a defect affects the software's operation, while priority describes how urgently the defect should be fixed.

Severity:

• Usually based on technical and user impact.
• Examples include system crash, data loss, security failure, or minor display error.
• A payment calculation error is normally high severity because it produces incorrect financial data.

Priority:

• Usually based on business urgency, release plans, customer commitments, and available workarounds.
• A spelling error on a heavily promoted home page may receive high priority even though its technical severity is low.

Examples:

• High severity, low priority: A crash in an obsolete administration feature that very few users can access.
• Low severity, high priority: An incorrect company name on the product's launch screen one day before release.
• High severity, high priority: Loss of customer transactions in the main payment workflow.
• Low severity, low priority: Slight misalignment of an icon on a rarely used settings page.

Severity and priority should therefore be assessed separately, because technical impact and business urgency are not always the same.

Bugs are not treated equally because they differ in impact, urgency, frequency, risk, and cost. Development resources are limited, so defects must be ranked according to their importance.

Major classification and prioritization factors include:

• Severity: The extent of functional damage, such as a crash, data corruption, or cosmetic problem.
• Priority: The urgency with which the organization needs the fix.
• Frequency: How often the defect occurs and how many users encounter it.
• Reach: Whether it affects one configuration, a customer group, or the entire user base.
• Business impact: Effects on revenue, reputation, compliance, or contractual commitments.
• Security and safety risk: Potential for unauthorized access, privacy violations, injury, or legal consequences.
• Availability of a workaround: A practical workaround may reduce immediate urgency.
• Release timing: A defect in a feature scheduled for imminent release may receive greater priority.
• Fix complexity and regression risk: The effort and danger associated with changing the affected code.
• Customer importance: Defects affecting critical customers or essential workflows may be handled sooner.

Classification helps teams spend effort on defects that present the greatest overall risk.

A typical bug life cycle consists of the following stages:

1. New: A tester or user discovers the defect and creates a report.
2. Triaged: The team checks validity, completeness, severity, priority, ownership, and duplication.
3. Assigned: The report is assigned to a developer or responsible team.
4. Open or In Progress: The assignee investigates the cause and begins work.
5. Resolved: The developer records a resolution, such as Fixed, Duplicate, Invalid, Cannot Reproduce, Won't Fix, or Works as Designed.
6. Fixed: A code or configuration change has been implemented and is available in a specified build.
7. Ready for Retest: The corrected build is delivered to testing.
8. Verified: The tester repeats the original steps and performs relevant regression tests.
9. Closed: The fix is accepted and no further action is required.
10. Reopened: If the problem remains, recurs, or was only partially corrected, the tester reopens the report with new evidence.

Actual status names vary between organizations. Regardless of terminology, each transition should have a clear owner, reason, and audit history.

These resolutions indicate that a report has been reviewed but will not proceed as an ordinary code fix.

• Duplicate: The same underlying defect is already recorded in another report. The duplicate should reference the original report so that evidence is not lost.
• Invalid: The report does not describe a genuine software defect, lacks meaningful information, or concerns the wrong product.
• Cannot Reproduce: The team cannot produce the failure using the supplied steps and environment. The report may be reopened if better evidence becomes available.
• Won't Fix: The defect is acknowledged, but the organization decides not to correct it because of low impact, high cost, release constraints, compatibility concerns, or planned product retirement.
• Works as Designed: The observed behavior agrees with the approved requirement or design, even if the reporter expected something different.

These resolutions should always include a clear explanation. They should not be used merely to reduce the number of open reports.

Bug triage is the structured review of reported defects to determine their validity, importance, ownership, and next action.

During triage, representatives from testing, development, product management, support, and other relevant teams may:

• Check whether the report contains enough information.
• Confirm that the behavior is a defect rather than an intended feature.
• Search for and link duplicate reports.
• Evaluate severity, priority, frequency, and business impact.
• Decide whether the bug blocks a release or requires immediate escalation.
• Assign the defect to the appropriate component and owner.
• Select a target milestone, sprint, or product version.
• Request additional logs, test data, or reproduction steps.
• Accept, defer, reject, or close the report with a documented reason.
• Review dependencies between defects and planned features.

Effective triage keeps the defect backlog accurate and ensures that critical issues receive timely attention.

A bug-tracking system is a software application used to record, organize, assign, monitor, and report defects throughout their life cycle.

Its major functions include:

• Centralized storage: Maintains defect descriptions, evidence, comments, and history in one repository.
• Unique identification: Assigns an ID to every report for reliable reference.
• Workflow management: Controls states such as new, assigned, resolved, verified, and closed.
• Ownership: Assigns bugs to developers, teams, or product components.
• Classification: Stores severity, priority, product, component, version, platform, and resolution.
• Search and filtering: Helps users locate related or duplicate defects.
• Notifications: Alerts interested users when reports change.
• Traceability: Links defects to requirements, tests, code changes, builds, and releases.
• Reporting: Produces dashboards and metrics for project monitoring.
• Audit history: Records who changed each field and when.
• Access control: Restricts sensitive security or customer information when necessary.

A tracking system improves coordination and provides a reliable record of defect-handling decisions.

A computerized bug-tracking system offers several advantages:

• Provides a single, searchable source of defect information.
• Supports consistent workflows and ownership.
• Preserves comments, attachments, and status history.
• Enables collaboration between testers, developers, managers, and support staff.
• Reduces lost or forgotten defect reports.
• Produces dashboards, trends, and release-readiness reports.
• Integrates with test automation, version control, and continuous integration tools.
• Supports notifications and service-level monitoring.

Its limitations include:

• Poorly written reports remain poor even when stored in a good tool.
• Excessive fields and complex workflows can discourage accurate reporting.
• Duplicate, outdated, or incorrectly classified reports can distort metrics.
• Setup, maintenance, training, and customization require effort.
• Automated notifications can create excessive noise.
• Sensitive reports require careful access control.
• Metrics may be misused to judge individuals instead of improving the process.

The tool supports defect management, but effective results still depend on disciplined reporting, triage, communication, and review.

Manual bug reporting and tracking relies primarily on human observation, data entry, communication, and status updates.

A typical process is:

1. A tester executes a test or explores the application and notices unexpected behavior.
2. The tester confirms the problem and searches for existing reports.
3. A new report is entered manually with a title, environment, preconditions, steps, expected result, actual result, severity, and attachments.
4. A triage team reviews the report, sets its priority, and assigns an owner.
5. The developer investigates the defect and manually updates comments and status.
6. When a fix is available, the tester receives the corrected build and performs retesting.
7. The tester closes the report if the fix works or reopens it with additional evidence if it fails.
8. Managers use lists, spreadsheets, emails, or tracking-system reports to monitor progress.

Manual reporting is flexible and well suited to usability, visual, and exploratory defects. However, it can be slow, inconsistent, error-prone, and difficult to scale without templates and process discipline.

Manual reporting is performed by a person who observes a failure, investigates it, and enters a report. Automated reporting uses tools or scripts to create or update reports when tests, monitoring systems, or production services detect failures.

Manual reporting:

• Provides human interpretation and business context.
• Is effective for usability, layout, workflow, and exploratory defects.
• Allows the reporter to simplify the scenario before submission.
• May be slow, inconsistent, incomplete, or affected by subjective judgment.

Automated reporting:

• Captures failures quickly and consistently.
• Can automatically attach logs, screenshots, stack traces, environment details, and test results.
• Is suitable for repeated automated-test failures and production exceptions.
• May create duplicate reports, noisy alerts, or reports without useful human context.

A strong process combines both approaches. Automation captures objective technical evidence and repeated failures, while humans validate the issue, assess user impact, remove duplicates, and provide meaningful prioritization.

An automated test framework can integrate with a tracking system through an API, webhook, command-line interface, or continuous integration plugin.

A typical workflow is:

1. The test framework executes a test suite in a known environment.
2. When a test fails, it captures the test name, build number, input data, exception, logs, screenshot, and stack trace.
3. The integration creates a stable failure signature from information such as the test name, exception type, and relevant stack frames.
4. It searches the tracking system for an open issue with the same signature.
5. If a matching issue exists, the integration adds the latest occurrence and evidence instead of creating a duplicate.
6. If no match exists, it creates a new report using a predefined template.
7. Rules assign the component, severity, owner, labels, and target version.
8. The report is linked to the failed pipeline, test result, source revision, and build artifact.
9. When later builds pass, the system may add recovery information, but human review should normally control final closure.

Authentication, rate limits, retry behavior, privacy, and the removal of passwords or personal data must be handled carefully.

Fully automated bug creation can overwhelm a tracking system if failures are submitted without filtering or interpretation.

Common problems include:

• Duplicate reports: Every execution may create a separate issue for the same defect.
• Noise from flaky tests: Unstable tests may repeatedly report failures that are not product bugs.
• Poor context: Raw exceptions may not explain the user impact or expected behavior.
• Incorrect classification: Automated rules may assign the wrong severity, component, or owner.
• Sensitive-data exposure: Logs and requests may contain credentials or personal information.
• Report flooding: A widespread outage may generate thousands of nearly identical issues.
• Premature closure: A temporary passing test does not necessarily prove that the root cause is fixed.

Controls include:

• Generate stable failure fingerprints and group matching occurrences.
• Apply retry and flakiness detection before creating an issue.
• Set rate limits and circuit breakers for mass failures.
• Use templates and validate required fields.
• Redact secrets and personal data from attachments.
• Require human triage for severity and closure decisions.
• Create one parent incident and link related failures during major outages.
• Periodically review automation rules and stale reports.

Bugzilla is a web-based, open-source defect-tracking system originally developed for the Mozilla project. It is used to record and manage bugs, enhancement requests, and related development work.

Principal features include:

• Organization of issues by product and component.
• Unique bug IDs and configurable status and resolution fields.
• Assignment of bugs to owners and quality-assurance contacts.
• Severity, priority, version, platform, and target-milestone fields.
• Comments and file attachments for logs, screenshots, patches, and test evidence.
• CC lists for users who want notifications.
• Dependency relationships through fields such as Blocks and Depends on.
• Duplicate detection and duplicate resolution.
• Simple and advanced search capabilities.
• Saved searches, reports, charts, and email notifications.
• Complete change history and configurable permissions.
• Support for keywords, flags, custom fields, and workflow customization.

Bugzilla provides a central, traceable repository through which teams can manage a defect from submission to closure.