Know? No. See!

What I have had most difficulty learning about drawing is probably also the most important point for me to learn: to draw what I see rather than what I know is there. Many years of experience tell me, for example, that a person’s shoulders are always the same width, regardless of how the person is turned from me. In actuality, however, the angle at which the person is turned affects the length their shoulders appear to be.

What I know is there are shoulders and arms and legs; what I see are lines and curves and shadows. When I draw what I know my mind gets in the way of recording reality; when I draw what I see my mind helps record it.

What I had most difficulty learning about testing was probably also the most important point for me to learn: to test what I see rather than what I know is there. Many years of experience tell me, for example, that all developers tend to make the same mistakes. In actuality, however, developers are different from each other and make different mistakes from each other, and they make different mistakes on each application they write.

What I know is there are boundary errors and duplicated hot keys and failures to validate input; what I see are issues which prevent my customers from doing what they want to do. When I test what I know my mind gets in the way of finding the most important issues; when I test what I see my mind helps find them.

Work what you see, not what you know.

[Original photo reference from https://www.3d.sk. See all my art at https://www.freelyoffered.com.]

*** Want a fun job on a great team? I need a tester! Interested? Let's talk: Michael dot J dot Hunter at microsoft dot com. Great testing and coding skills required.

Comments

• Anonymous
  March 12, 2008
  PingBack from http://msdnrss.thecoderblogs.com/2008/03/12/know-no-see-2/

• Anonymous
  March 12, 2008
  Goethe at one point expressed a desire to see what everyone has seen, and to think what no one has thought.   Your comments on learning to draw remind me how hard it is to see even the things that are in plain sight--never mind the things that are invisible; mind-stuff.  Software--and the systems surrounding it--are mostly intangible.  So I'd suggest testing what you see <i>and</i> things that you can't necessarily see directly.  Work what you see, <i>not just</i> what you know.  And work what you know, <i>not just</i> what you see.

• Anonymous
  March 12, 2008
  Perspective (http://www.khulsey.com/perspective_basics.html) is the first thing learning artists forget. An exercise to help combat the mind's tendency to impose logic on what you're drawing is to draw the same thing viewed upside down.  Your mind abstracts itself from its known preconceptions and you eventually get a feel for perspective rather than preconceptions. Testing is similar, once you know how to use a piece of software your mind then has preconceptions about what should occur or how things must work.  But, I don't think using software upside down would help combat that :-)

• Anonymous
  March 12, 2008
  You have just articulated the fundamental difference between development and testing. Development is about imagining something that isn't there, holding the image so strongly that it can be made real over long stretches of time, great effort and several layers of indirection. Testing is about seeing what's there.

• Anonymous
  March 14, 2008
  Nice drawings!  I'd like to take an art class but there never seems to be time.  I don't post often but read your blog often.  I was wondering if you might be able to help me with a question?  I appologize that this is off-topic of your post. I need to understand better the theory/approaches of maintaining load during a load/volume testing.  Not the coding end. The industry best practices type of thing.  At first glance it would seem to be a simple topic but when you dig deeper, I end up with a lot of questions: For example if I'm given only short workflow scripts by the customer (and they answer all my questions about the existing production environment user base with an "I don't know?"), is it reasonable that I would login, perform actions, then logout, repeat (of course with +/-20% variance for user thinktimes).... or is it assumed that I should be looping these short scripts before logging out....but then what if loop #1 generates an error & that error condition continues onward through the rest of the loop repeatition - didn't I just negate 1 user's worth of load during part of my testing (especially if it happens that it's really a bunch of my users who receive errors not just one.)  The short version of that question is: "Does Microsoft have any best practices for load generation?" Thank you  

• Anonymous
  March 17, 2008
  I can very well relate the same thoughts which you have with wind or air which means that the focus of testing mission should not be carried away by the so many available terminologies. The goal and aim of testing should always be to test what is seen.In todays so complex world testers seem to be driven away by real testing  mission and instead they start testing only what they know which means always limited by their knowledge. hence as you very well said that what you see and what you know should be combined to make best use of testing mission.

• Anonymous
  March 28, 2008
  Paula: I don't know much about load testing. I suggest you post your question to the MSDN Tester Center's (http://msdn.microsoft.com/testercenter) forums, where load testing experts are copious.