It’s a tester’s natural tendency to run to their bug tracking tool as soon as they find a bug, but sometimes that’s not the wisest course of action. It’s possible that the bug you’re seeing is just the tip of the iceberg and underneath is a more serious issue. By filing that initial bug report, you might be distracted away from doing a deeper investigation of the issue.
Let me share a real world example.
We’re currently working on a new syntax for ASP.NET and we want this new syntax to “light up” (e.g., keywords should be highlighted correctly) in Visual Studio editor just like classic ASP.NET syntax. A few months ago, we noticed that syntax highlighting disappeared if you renamed the file extension that was currently open in the editor. The workaround, close and re-open the file, seemed simple, and this user scenario seemed unlikely so we passed on fixing the bug at that time.
Fast forward to a few weeks ago. The same issue is reported again but this time we decide it must be fixed. What? That’s the same bug we raised a long time ago. Why the urgency all of a sudden?
It turns out the problem also occurs if you simply rename the file. Not just the extension. Ah, now that’s a common user scenario that needs to be fixed.
So why didn’t we catch that variation of the bug the first time around? I think it’s because we ran into the initial problem (file extension rename), reported the issue and then diverted our attention to the next test scenario. The first way the bug manifested itself simply distracted us from doing a deeper investigation. Had we thought about the issue for a few minutes, I’m almost certain we could have identified the more serious user scenario. Argh.
Lesson learned.
Happy testing!
No comments:
Post a Comment