Working with bugs is a key competency for any QA specialist. Understanding what a bug is, its lifecycle, how to properly document and track it forms the foundation of professional testing. In this comprehensive guide, we’ll examine all aspects of working with software defects.

What is a Bug: Definition and Typology

Bug Definition

Bug (Defect, Issue) is a deviation of the actual program behavior from the expected result described in requirements, specifications, or common sense logic.

ISTQB formal definition: A defect is an imperfection or deficiency in a work product where it does not meet its requirements or specifications.

Bug Types

1. Functional (as discussed in Security Testing for QA: A Practical Guide) bugs — application functionality violations:

  • Feature doesn’t work at all
  • Feature works incorrectly
  • Feature doesn’t work per specification
  • Stated functionality is missing

Example: “Add to Cart” button doesn’t add item but redirects to homepage.

2. UI/UX bugs — interface problems:

  • Design mockup mismatches
  • Alignment, spacing, font issues
  • Non-working interface elements
  • Poor responsiveness
  • Color scheme, contrast problems

Example: On mobile devices, text overflows screen boundaries, buttons overlap each other.

3. Logic bugs — business logic errors:

  • Incorrect calculations
  • Wrong condition handling
  • Formula errors
  • Business rule violations

Example: During checkout, 20% discount applies instead of stated 10%, leading to company losses.

4. Performance bugs — speed and resource problems:

  • Slow page loading
  • High CPU/memory consumption
  • Memory leaks
  • Long query execution

Example: Catalog page loads 15 seconds instead of required 2 seconds.

5. Security bugs — vulnerabilities threatening data:

Example: API endpoint returns all user data without access rights verification.

6. Compatibility bugs — platform-specific problems:

  • Doesn’t work in specific browser
  • iOS/Android issues
  • OS version incompatibilities
  • Conflicts with other software

Example: Application crashes on iOS 14 but works on iOS 15+.

7. Localization bugs — translation problems:

  • Untranslated strings
  • Text truncation in other language
  • Wrong date, number, currency formats
  • Cultural mismatches

Example: Application shows dates in MM/DD/YYYY format for all regions, including Europe where DD/MM/YYYY is standard.

Bug Life Cycle

A bug goes through several stages from discovery to closure. Understanding the lifecycle is critically important for effective defect management.

Classic Bug Life Cycle

1. New

  • Tester discovered and documented bug
  • Bug hasn’t been reviewed by team yet
  • Awaiting triage

2. Open / Assigned

  • Bug passed triage
  • Recognized as valid defect
  • Assigned to developer for fixing
  • Priority and severity set

3. In Progress

  • Developer started working on fix
  • Bug is in active development
  • May require additional information

4. Fixed

  • Developer completed fix
  • Code committed and merged
  • Bug ready for tester verification
  • Build/version where fixed is specified

5. Pending Retest

  • Fix deployed to test environment
  • Awaiting tester verification
  • May be included in release candidate

6. Retest

  • Tester actively verifying fix
  • Original scenario retesting
  • Adjacent areas regression checking

7. Verified / Closed

  • Tester confirmed bug is fixed
  • Functionality works correctly
  • No side effects identified
  • Bug closed

Alternative Statuses

Rejected / Invalid

  • Behavior matches requirements
  • Problem not reproducible
  • Is a task, not a bug
  • Duplicate of existing bug

Cannot Reproduce

  • Developer can’t reproduce problem
  • Requires additional information from tester
  • May be environment-specific

Deferred / Postponed

  • Bug recognized as valid but fix postponed
  • Not critical for current release
  • Will be fixed in future versions
  • Added to backlog

Won’t Fix

  • Fix too expensive
  • Affects extremely rare edge case
  • Obsolete functionality will be removed
  • Business decided not to invest in fix

Reopened

  • Bug wasn’t completely fixed
  • Problem manifests in other scenarios
  • Regression after another change
  • Returns to developer

Life Cycle Diagram

New → Open/Assigned → In Progress → Fixed → Retest → Verified/Closed
  ↓         ↓              ↓           ↓        ↓
  └→ Rejected              └→ Cannot Reproduce  └→ Reopened → (back to In Progress)
            ↓
            └→ Deferred/Won't Fix

Bug Classification: Severity and Priority

Proper bug classification is critical for effective defect management and team work prioritization.

Severity — Technical Impact

Severity measures bug’s technical impact on system. This is an objective characteristic.

Critical / Blocker

  • Application crashes or completely unavailable
  • Data loss or corruption
  • Critical security (as discussed in Dynamic Testing: Testing in Action) breach
  • Blocks testing continuation
  • Makes main functionality unavailable

Examples:

  • Users can’t log into system
  • During checkout, money charged twice
  • Production database deleted on certain action
  • SQL injection allows access to all user data

Major / High

  • Significant functionality works incorrectly
  • Workaround exists but inconvenient
  • Affects majority of users
  • Significant deviation from requirements

Examples:

  • Search doesn’t work, but users can find products through categories
  • Email notifications not sending
  • PDF export doesn’t work
  • Form validation passes incorrect data

Medium / Normal

  • Functionality works but with flaws
  • Minor deviation from requirements
  • Affects small user group
  • Simple workaround exists

Examples:

  • Button has wrong color
  • Text typos
  • Minor UI alignment issues
  • Non-critical fields don’t save

Low / Minor

  • Cosmetic problems
  • Doesn’t affect functionality
  • Extremely rare edge cases
  • Problems in unimportant areas

Examples:

  • Wrong margin in footer
  • Console warnings in DevTools
  • Tooltip appears with slight delay
  • Incorrect display in obsolete browser

Priority — Business Importance

Priority measures fix urgency from business perspective. This is a subjective characteristic depending on context.

P1 / Urgent

  • Needs immediate fix
  • Blocks release
  • Business critical
  • May require hotfix

P2 / High

  • Must be fixed in current release
  • Important for main user scenario
  • Affects key metrics

P3 / Medium

  • Should be fixed in upcoming releases
  • Added to backlog
  • Fixed when resources available

P4 / Low

  • Nice to have
  • Fixed when there’s free time
  • May never be fixed

Severity vs Priority Matrix

Severity ↓ / Priority →P1 UrgentP2 HighP3 MediumP4 Low
CriticalApp down before Black FridayDatabase crashes in rare scenario--
MajorPayment not workingReport export brokenAPI slow-
MediumTypo in campaign nameFilters work incorrectlyUI bug on internal page-
Low-Brand color inaccurateWrong marginConsole warning

Important to understand:

  • High Severity + Low Priority: Critical bug in feature almost nobody uses
  • Low Severity + High Priority: Typo in CEO name on homepage
  • Severity determined by technical team, Priority by product team and business

How to Properly Report Bugs: Best Practices

Bug report quality directly affects fix speed. Poor bug report = wasted team time.

Mandatory Bug Report Elements

1. Brief but Informative Title (Summary)

❌ Bad:

  • “Not working”
  • “Bug on login page”
  • “Button problem”

✅ Good:

  • “Login button does not respond on iOS Safari 15.2”
  • “Payment form accepts expired credit cards”
  • “Dashboard crashes when loading >1000 records”

Formula: [Area] What doesn't work under which conditions

2. Environment

  • Operating System: Windows 11, macOS 14.2, iOS 17.1
  • Browser and version: Chrome 120.0.6099, Safari 17.2
  • Application version: 2.5.3 (build 456)
  • URL: https://app.example.com/dashboard
  • Device type: iPhone 15 Pro, Desktop 1920x1080
  • Network conditions: WiFi, 4G, Offline mode

3. Steps to Reproduce

Detailed step-by-step instruction:

Prerequisites:
- User logged in as admin
- At least 5 products in cart

Steps:
1. Navigate to https://app.example.com/cart
2. Click "Apply Coupon" button
3. Enter coupon code "SAVE20"
4. Click "Apply"
5. Click "Proceed to Checkout"

Expected Result:
- Coupon discount 20% applied
- Total price reduced by 20%
- User redirected to checkout page

Actual Result:
- Coupon appears applied in UI
- Total price NOT reduced
- Error in console: "calculateDiscount is not defined"
- User CAN proceed to checkout with wrong price

Golden Rules for Steps to Reproduce:

  • Write from user perspective, don’t assume context
  • Each step should be specific and actionable
  • Specify exact data (not “enter email”, but “enter test@example.com”)
  • Include prerequisites
  • Number steps

4. Expected and Actual Result

Always specify BOTH:

  • Expected Result: what should happen per requirements
  • Actual Result: what actually happens

5. Severity and Priority

Indicate reasonably with explanation (especially if high severity/priority).

6. Attachments

  • Screenshots — mandatory for UI bugs
  • Video — for complex scenarios, crashes, animations
  • Logs — browser console, server logs, mobile logs
  • Network traces — for API/network bugs
  • Crash dumps — for application crashes

Tools:

  • Loom, CloudApp — for screen recording
  • Chrome DevTools — for network/console logs
  • Postman — for API requests

7. Additional Information

  • Frequency: Always / Sometimes / Rarely
  • Workaround: if there’s a way to bypass problem
  • Related issues: links to related bugs
  • Impact: assessment of user/business impact

Quality Bug Report Checklist

  • ✅ Brief, informative title
  • ✅ Complete environment information
  • ✅ Detailed reproduction steps
  • ✅ Expected and actual results clearly separated
  • ✅ Severity and Priority justified
  • ✅ Screenshots/video/logs attached
  • ✅ Verified bug is not duplicate
  • ✅ Bug reproduces consistently
  • ✅ Unnecessary steps removed (minimal reproduction scenario)

Common Reporting Mistakes

❌ Multiple bugs in one report

  • One bug = one report. Don’t combine multiple issues.

❌ Subjective descriptions

  • Don’t write “looks strange”, “works slowly”
  • Write specifically: “loading takes 8 seconds instead of required 2”

❌ Missing reproduction data

  • “Bug when entering email” — which email? Which field? Which page?

❌ Emotional tone

  • “Terrible bug”, “How could this get into release”
  • Be professional and objective

❌ Not checking relevance

  • Verify bug still reproduces before reporting

Critical Bug Examples from Real Practice

Studying real examples helps understand quality testing importance.

1. Therac-25 (1985-1987) — Medical Accelerator

What happened: Radiation therapy machine Therac-25 had a control system bug that delivered lethal radiation doses under specific operator action sequences.

Technical cause:

  • Race condition in software
  • No hardware safety interlocks (relied only on software)
  • Poor error handling — system showed cryptic message “Malfunction 54”

Consequences:

  • 6 patients died
  • Multiple overdose victims
  • Multi-million dollar lawsuits
  • Complete device usage halt

QA Lesson:

  • Safety-critical systems require especially thorough testing
  • Importance of clear error messages
  • Hardware + Software redundancy in critical systems
  • Can’t ignore race conditions

2. Ariane 5 (1996) — $370M Rocket

What happened: First Ariane 5 launch ended in self-destruction 37 seconds after liftoff.

Technical cause:

  • Integer overflow in navigation system
  • Code was reused from Ariane 4
  • Ariane 5 velocity was higher, causing overflow when converting 64-bit float to 16-bit integer
  • Exception handling led to shutdown of both redundant systems simultaneously

Consequences:

  • $370 million loss
  • 4 scientific satellites destroyed
  • Program delayed by years

QA Lesson:

  • Must test in real conditions, not just per old specifications
  • Code reuse requires regression testing with new parameters
  • Critical calculations need boundary value checking
  • Redundant systems shouldn’t fail simultaneously

3. Knight Capital (2012) — $440M in 45 Minutes

What happened: Trading software update led to system sending millions of erroneous trading orders.

Technical cause:

  • When deploying new code to 8 servers, one server wasn’t updated
  • On non-updated server, old unused function activated
  • This function started buying stocks at high price and selling at low in huge volumes
  • Error noticed after 45 minutes

Consequences:

  • $440 million losses
  • Company bankrupted and bought out
  • SEC fines $12 million

QA Lesson:

  • Critical importance of complete deployment on all servers
  • Smoke tests after each deployment
  • Real-time monitoring and alerts
  • Kill switch availability for critical systems
  • Testing on production-like environment

4. Toyota (2009-2011) — Unintended Acceleration

What happened: Toyota cars unexpectedly accelerated without pressing gas pedal.

Technical cause (partially confirmed):

  • Stack overflow in electronic throttle control system
  • Insufficient memory allocation
  • Poor code: global variables, spaghetti code, insufficient error checks
  • Possible bit flips from cosmic rays (not joking)

Consequences:

  • 89 deaths (claimed)
  • 9+ million vehicle recall
  • $3+ billion fines and settlements
  • Massive reputation damage

QA Lesson:

  • Automotive software requires strictest standards (ISO 26262)
  • Code quality importance in embedded systems
  • Electromagnetic interference testing
  • Hardware-in-the-Loop (HIL) testing mandatory
  • Static code analysis and code reviews critical

5. GitHub (2012) — All Repository Deletion

What happened: Backup system bug could lead to production database deletion.

Technical cause:

  • Script that should delete files from /tmp/ received empty variable
  • Result was rm -rf / instead of rm -rf /tmp/backups/
  • Fortunately, discovered on test system before production

Consequences:

  • None (discovered before production)
  • But was wake-up call for industry

QA Lesson:

  • Always validate variables for empty values before destructive operations
  • Testing backup/recovery procedures
  • Never run rm -rf with variables without validation
  • Dry-run mode for critical scripts
  • Code review for infrastructure code

6. AWS S3 Outage (2017) — Typo Cost Billions

What happened: AWS employee executed command to remove small number of servers but accidentally removed much more, leading to 4-hour S3 outage.

Technical cause:

  • Human error in command input
  • No protection from accidental mass deletion
  • Recovery process took several hours

Consequences:

  • Millions of sites unavailable
  • Losses estimated at $150+ million for entire internet economy
  • Amazon lost about $3-4 million themselves

QA Lesson:

  • Even experienced engineers make mistakes
  • Critical operations should require confirmation
  • Rollback strategy should be fast
  • Testing disaster recovery procedures

Best Practices for Team Bug Work

1. Bug Triage

Regular meetings (usually daily or several times weekly) for:

  • New bug review
  • Validation and prioritization
  • Assignee designation
  • Duplicate removal

Participants: QA Lead, Dev Lead, Product Manager

2. Bug Metrics

Track metrics:

  • Bug detection rate — how many bugs found
  • Bug fixing rate — how many fixed
  • Bug leakage — how many reach production
  • Reopen rate — how many bugs reopened
  • Average time to fix — average fixing time

3. Root Cause Analysis (RCA)

For critical bugs, conduct RCA:

  • Why did bug occur?
  • Why wasn’t it discovered earlier?
  • What processes need improvement?
  • How to prevent similar bugs?

4. Regression Prevention

  • Add automated tests for each significant bug
  • Maintain regression test suite
  • Conduct impact analysis for changes

5. Communication

  • Use professional tone
  • Focus on problem, not people
  • Don’t blame (“who wrote this code?”)
  • Constructively propose solutions

Conclusion

Working with bugs is both art and science. Quality bug reporting saves entire team time, accelerates fixes, and improves product quality.

Key Takeaways:

  1. Bug is any deviation from expected behavior, whether functionality, UI, or performance.

  2. Understanding lifecycle helps effectively track status and not lose defects.

  3. Severity and Priority are different things. First is technical, second is business. Learn to distinguish them.

  4. Bug report quality is critically important. Poor report = wasted team time = slow fixing = more production bugs.

  5. Study real examples of critical bugs. History teaches, mistakes cost dearly, lesson is priceless.

  6. Bug work is team process. Testers, developers, managers — all must interact effectively.

Remember: each bug found and properly documented is a problem users won’t see. It’s investment in product quality and company reputation.

Next steps:

  • Study SDLC and STLC to understand where testing fits in development
  • Review testing principles for deeper understanding
  • Practice writing bug reports on real or training projects