Devs have a special ability to talk testers out of bugs by claiming said bugs cannot be fixed. It goes something like this…
Tester: This UI control doesn’t do what I expect.
Dev: It’s not a bug. It’s a technology constraint. It is not possible to make it do what you expect.
My current AUT uses a third party .Net grid control called “ComponentOne” and I often hear the following:
Dev: It’s not OUR bug. It’s a ComponentOne bug.
I’m fine with these dev responses and even grateful for the info. Where it becomes a problem is when I get soft and don’t log the bug. Criteria for a bug should not include whether we believe it can be fixed or not. Log it! There is so much value in even non-fixable bugs!
Our bug list should capture what is known about the quality of the AUT. If we know the UI widget does not work the way we want it to, let’s document that. Who knows, if these non-fixable UI widget bugs keep getting logged, maybe we can justify using a different UI widget. But a more likely result, from my experience, is that devs will do everything in their power to fix everything on that bug list. And they will suddenly become more creative and write a hack for the technology constraint that earlier looked impossible to overcome.
So don’t be fooled like the storm troopers in front of the Mos Eisley Cantina. If you start hearing “These are not the bugs you’re looking for”, snap out of it!
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
This trap is all to easy to fall into when you compound the importance of "numbers." When you're so worried about the bug count, that you start looking for ways not to add them, you know you've got a problem. Perhaps that's an idea for another post.
I agree, but I also think it's a form of blackmail for those devs who hate to have bugs left in their queues, their should be a special "These bugs exist because C1 support is terrible and they won't fix their bugs" queue in my opinion. Other reputable component vendors don't need their own queue because they actually fix their issues most of the time.
So true. I caught on to these Jedi mind tricks early on in my testing career. After a while I had some Jedi mind tricks of my own as this scene was getting too repetitive:
"It's still a bug. Whether you want to fix it or not, when, and in what priority is a different story. I'll open a ticket, do with it what you wish afterward."
BTW, loving your blog! Write some more.