Staying focused on testing OneNote even while we use it

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


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


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,