We talked about a key concept of our testing earlier this week and I think it is worth sharing.  Let me start with an imaginary scenario:

 

While working on OneNote, we introduce this type of bug into our product:  if you add a table which has an image in it, you can't add bullet points to text anywhere on the page.  Obviously,  this is a somewhat severe bug and we would file, prioritize, fix and verify the fix.  In the meantime, though, we still use OneNote in our day to day work. 

 

The habit we would all form is obvious: we would quickly train ourselves to avoid the problem so we wouldn't have to see it blocking our work.  We would start with not putting images in tables, and possibly this would lead to us avoiding tables altogether.

 

While this situation I describe is overly contrived it does serve to demonstrate the "blinders" we can start to wear.  We get so used to working around the bug, that we may forget about it, or get so used to our workarounds that we lose the  urgency to fix it,  or (in this case) train ourselves to quit using tables in OneNote.  We get blinded to the bug to the point we don't see it anymore. 

 

The challenge for testers is to stay focused on all aspects of our product every day, to be diligent about filing and tracking the bugs we encounter, and maintain that focus throughout the time it takes us to develop OneNote.  If there is some minor problem, we definitely don't want to lose focus on it.  To me, OneNote is all about getting my information into my tablet quickly so I can keep it with me.  I don't want to be delayed while OneNote starts (to mention performance), or have to work around whether or not I can have a table with an image (to go back to my example) or to have a screen reader not be able to recognize the File menu (to mention accessibility). 

 

For any of these areas, I can not afford to get used to working around problems.  I also cannot afford to delay entering a bug when I encounter it - I may forget to do it, or forget some key detail needed to reproduce the bug.  (As a side note [no pun intended],I tend to keep those details in notepad.  When I hit a bug, OneNote usually becomes unavailable  for keeping notes on my  bugs since I inevitably wind up connecting a debugger to OneNote.  At that point, OneNote stops running while I get a memory dump and other relevant information.  I joke that we really need to develop an application that tracks all this information needed for me…).  Once I enter the bug, I need to push for a timely resolution, in part so that no one else develops a workaround which may block a key scenario which needs coverage.

 

It's a balancing act that we have to get right.

 

Questions, comments, concerns and criticisms always welcome,

John