• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Satisfice, Inc.

Software Testing for Serious People

Rapid Software Testing A Context-Driven Methodology
  • Home
  • About
    • Privacy Policy
  • Methodology
    • Exploratory Testing
    • Reasons to Repeat Tests
  • Consulting
  • Classes
    • James Bach’s Testing Challenge
    • Testimonials
    • RST Courses Offered
    • Testers and Automation: Avoiding the Traps
    • Rapid Software Testing Explored
    • Rapid Software Testing Applied
    • Rapid Software Testing Managed
    • Rapid Software Testing Coached
    • Rapid Software Testing Focused: Risk
    • Rapid Software Testing Focused: Strategy
  • Schedule
  • Blog
  • Contact
  • Resources
    • Downloads
    • Bibliography: Exploratory Process
    • Bibliography: Risk Analysis
    • Bibliography: Coaching
    • Bibliography: Usability
    • Bibliography: My Stuff From IEEE Computer and IEEE Software Magazines
    • Bibliography: The Sociology of Harry Collins

Dead Bee Heuristic

Published: February 17, 2006 by James Bach 2 Comments

Have you ever had a software problem that disappeared even when you did nothing to correct it? Or have you ever fixed a bug by doing something that seems as if it shouldn’t have fixed anything?

Whenever that happens to me, I A) remain wary, and B) remove the fix so that by seeing the problem again I have additional evidence that the “fix” was truly the fix. I call this is the dead bee heuristic, because if there’s a bee in my living room, I don’t want it to mysteriously disappear, I want to see it fly out my window or be dead on my floor.

This applies to testing situations, too. If I change a data file and see that it no longer crashes the application I’m testing, the next thing I do is change it back again so I can see the crash one more time.

“Say, was you ever bit by a dead bee?…You know, you got to be careful of dead bees if you’re goin’ around barefooted, ’cause if you step on them they can sting you just as bad as if they was alive, especially if they was kind of mad when they got killed. I bet I been bit a hundred times that way.” — Walter Brennan as “Eddie” in To Have and Have Not

And always bear in mind that killing the “bee” may not have solved the real problem, or may have created new problems.

Filed Under: Exploratory Testing, Heuristics

Reader Interactions

Comments

  1. Valentijn says

    18 August 2014 at 10:42 am

    In my 9 years of test experience I have whitnessed the ‘dead bee heuristic’.

    I have even seen something stranger… once I found a bug, but I only saw it 1 time. After that, I never saw it again. I talked about it with colleagues and friends but none of them could believe the bug. I kept saying and telling what I had seen. But they all said the same thing “show me the bug”, “Can you reproduce it?”, well you know how this story goes.

    I never could reproduce it.
    Untill on 1 day we had a large meeting with 20 people on a large screen. The person who gave the demo reproduced the bug. It blinked on screen before everyone’s noses. Everybody believed me from that moment. *”you saw the Windows background wallpaper through the application for a split second.”
    However, we never found the cause and none of the programmers could reproduce the bug ever since.

    We don’t even know if the bug is still in the application or solved because of ongoing development so to speak.

    But the thing is: How do you call such type of bug? How should it be named? A mystery? 🙂

    [James’ Reply: It’s a hard to reproduce bug.]

    Reply
  2. Steve says

    10 June 2021 at 12:33 pm

    Please don’t kill bees. Pollinators are our friends.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search

Categories

  • About Me (17)
  • Agile Methodology (14)
  • AI and Testing (4)
  • Automation (20)
  • Bug Investigation and Reporting (9)
  • Buggy Products (24)
  • Certification (10)
  • Context-Driven Testing (44)
  • Critique (46)
  • Ethics (22)
  • Exploratory Testing (34)
  • FAQ (5)
  • For Newbies (25)
  • Heuristics (28)
  • Important! (20)
  • Language (35)
  • Management (20)
  • Metrics (3)
  • Process Dynamics (27)
  • Quality (8)
  • Rapid Software Testing Methodology (23)
  • Risk Analysis (13)
  • RST (5)
  • Scientific Method (3)
  • Skills (30)
  • Test Coverage (8)
  • Test Documentation (8)
  • Test Oracles (5)
  • Test Reporting (11)
  • Test Strategy (26)
  • Testability (4)
  • Testing Culture (96)
  • Testing vs. Checking (18)
  • Uncategorized (12)
  • Working with Non-Testers (7)

Blog Archives

Footer

  • About James Bach
  • Satisfice Blog
  • Bibliography: Bach on IEEE
  • Contact James
  • Consulting
  • Privacy Policy
  • RST Courses
  • RST Explored
  • RST Applied
  • RST Managed
  • RST Coached
  • RST Focused: Risk
  • RST Focused: Strategy
  • RST Methodology
  • Exploratory Testing
  • Testing Training
  • Resources
  • Bibliography: Exploratory
  • Bibliography: Risk Analysis
  • Bibliography: Coaching
  • Bibliography: Usability
  • Bibliography: The Sociology of Harry Collins
  • Schedule
  • Upcoming Public Classes
  • Upcoming Online Classes
  • Public Events
  • Tester MeetUps

Copyright © 2025 · News Pro on Genesis Framework · WordPress · Log in