Anchoring and Attentional Bias...

I thought I might take a bit of a deeper look into cognitive biases... I decided to start going through the list that I mentioned in my previous blog... and "begin at the beginning" to quote Lewis Carrol...  on the list that is...

Anchoring - "the human tendency to rely too heavily, or "anchor," on one trait or peice of information when making decisions."

Real World Example:  My oldest daughter was looking for a new "used" car.  Her last vehicle went to, let's say, about 145,000 miles before it was in need of a new engine.  While assisting her in looking for another vehicle, she focused solely on the number of miles that were listed for the vehicle.  She was not concerned with the make/model/year/expectancy/maintainence it recieved/etc.  Based on her limited experience with vehicles, and the fact that that particular vehicle may have needed the new engine at 145,000 miles due to excessive wear and subsequent neglect of other parts, she was "anchored" into believing that mileage was the goal of the purchase.

Possible Testing Example:  A new tester works for Project A for a year or so.  Project A consists of one large customer.  The tester's job is XYZ, the customer does all of the Acceptance Testing and provides the bugs to the team that they want fixed when it comes to usability.  That tester now transfers over to Project D.  Project D distributes their product/application/system to a wide variety of customers.  The tester is now faced with the "anchor" of how things were done on Project A.  If not careful to find out the differences in what is expected of them in Project D, the project will indeed suffer for quite some time.  If they wish to "sail" through this project and give the stakeholders the necessary feedback they need on usability, they need to pull up the "anchor" of their belief that the "customer is always right".  They will need to now look at usability testing in a new light, based on general standards, using heuristics and oracles.  (Here is a great post by Michael Bolton concerning oracles.)

Attentional Bias - "the tendency of emotionally dominant stimuli in one's environment to preferentially draw and hold attention."

I did a little research into this particular cognitive bias and it appears to be emotional in a largely negative way.  I would almost want to group this in with cultural differences between groups or individuals as well as taking into account their own personal backgrounds.  I would think this is a tough one to even acknowledge and analyze if you don't think about it "on purpose".

"Maybe" a Real World Example:  I worked under the management of my father for six years.  During this time, it was quite evident to me that he was a male chauvenist.  There were four of us working under his management:  two females, two males.  The males did less work and got more money.  After the business was no longer in existence, I confronted him on this and was told, "so and so should get more money, he is the provider of his family".  He always believed... and showed his beliefs... that males were the "providers" and thus they should earn more money.  (Note:  It never crossed his mind that I am provide for my family, it only crossed his mind that I am female.)  This burned into my brain a bias - an "emotional" bias - towards "hearing" when anyone mentions gender in the workplace and in general.

"Maybe" a Possible Testing Example:  A female tester works on a team that includes only male developers.  They offer to give her help on testing.  She sees it as they are thinking she is "less smart" than a male tester would be and she shuts down her listening skills. 

This was a hard one for me to really wrap myself into.  Either I am totally ignoring this bias or I don't really have it.  My "emotional"/attentional biases are easy for me to spot.  I know who I am and where I have come from.  They rarely, if ever, surface in my career.  It is too "emotional" for me to think about anyway... I rely too much on logic...

Because this particular bias was related to "emotion", I recalled a presentation from Michael Bolton on Emotions and Oracles.  I think, that if you find yourself wanting to take this bias and investigate it further with your testing career, and even if you don't... that you read this.  Even though I am thought of by most, that think they know me, to be really the daughter of Spock, even I learned much from reading it.

Thinking About Thinking... again...

I was thinking about thinking... again... I wanted to check out anything new on the subject out in the vast world of cyberspace (is that word still used?  Cyberspace?)...

I checked out some topics on some of the websites and blogs that I usually go to for innovation/new ideas/thoughts, but I didn't find anything that actually caught my attention.  Perhaps I was thinking too hard about thinking...

I decided to just run a search on the subject of Critical Thinking and see what Google would throw my way in videos... I did not feel like reading tonight, I just wanted to listen/watch for a change.

Nights like tonight make me feel a bit old.  I am amazed at what is out there in a world of "intelligent" human beings... there is a lot of stuff out there that doesn't exactly hit the mark for the word "thinking" even though the search criteria is requesting such.

I came across a really noisy video during my search to find something new on Critical Thinking.  I ended up watching it twice because my 18-year-old daughter jumped up from what she was doing to see it.  She laughed aloud watching the video.  I am not sure she was able to catch any of the background message, but it was there, if you could tune out all that noise.

Here is the video for The Critical Thinking Song:

The message in the video, in case you could not tune out the "noise": 
Step One:  Be willing to say "I don't know"
Step Two:  Define your terms
Step Three:  Be open minded
Step Four:  Produce ideas
**Consider the source
**Seek out alternative views
**Ask questions
**Look for at least three answers
**Lay your cards down on the table
**Write about it
Step Five:  Accept changing perspectives
**Come up with your own conclusion

Maybe someone else out there will find this video just as humorous as my daughter did and be able to remember the steps listed in order to remember to think critically.  I must say that I have seen Step 1 to be lacking in most projects that I have worked on, sadly.  Admitting you don't know doesn't mean it is the end of the world, it means the answer needs to be found.  I prefer "I don't know" to a lame excuse or not-quite-right answer... every time... It is not a weakness to say this, it is admirable when true.  For the video... I admit the cat made me laugh...

Needless to say, after the noise, I was less lazy feeling... never mind the videos... give me words.

Somewhere in my research, I found the term "cognitive biases".  Having read numerous books and other peices on biases over my lifetime, I decided to change my search criteria to that.

I found a list of cognitive biases.  I think for tonight I will consider these biases and if they affect me or not... quietly... :)  I bet one of those biases makes me think twice about the Critical Thinking Song...

On the Two Sides of Communicating...

I just watched/listened to a TED talk given by Julian Treasure on "5 ways to listen better".

Take a few moments to "listen" to it, if you will....

The "filters" that Mr. Treasure includes in the presentation remind me of personal bias' that we have when we filter any information - written/heard/seen.  And how it is important to remember to at least try to see outside of where we are/have been in order to communicate better. 

Listening is an important skill, that although it is listed as a "soft" skill in most job requirements, it is more often than not, a "hard" skill to acquire.

The speaker used the acronym "RASA" (you will have to listen to the talk in order to hear where that comes from) to give tips for better listening skills.

I wish the talk had been more in depth, lasted longer...  For many years, I have had the routine of taking time out for silence.  It is something that scares so many people these days, but it is something that was so natural not too many decades ago. It is something I need to have to face the day.  It brings me balance.

To clear the brain of noise, to "hear" what is naturally occuring around you, can help to not only allow better listening, but better appreciation for hearing.

I also caught up on another blog I often read, Metacool, one post that particularly caught my eye was titled "Effective storytelling, a countermeasure against complexity".

Together the posts made me think about things that are a value to me, that make me think about humanity and communication in "deeper" ways. 

Storytellers have always fascinated me.  As a young person, I always loved power outages.  While the adults may have not liked thinking about the meat thawing out in their freezers, I loved that fact that folks were just not as distracted as they generally are.  The adults would start to tell "stories" to get past the silence.  It was wonderful.  I remember such things as if they were burned in my soul.

I have met other storytellers along the road, and no matter what is going on around me at the time, I indeed will listen intently.  They are a rare breed, few and far between, perhaps because the world is so "noisy" today.

Both of these subjects combined have made me think of the two sides of communication... the speaking and the listening... and they have made me think of what I can improve on in my own self.

What I Learned from "The Hitching Post"

When I was in high school, many moons ago, I worked on the school newspaper.  It was a great experience that I remember fondly to this day.  One of the funniest things that happened was when the editor (another student) had accidently applied his name to an article I had written.  I was able to “pay him back” in the April Fool's Day  edition by submitting an article where he had been arrested for it…

I learned a lot about gathering information and sticking to the facts in that class.  The instructor was passionate about hammering home a couple of important things to remember when submitting an article.  And, believe me; it did not get published if it did not pass the test.  The first thing he hammered home was "just the facts, ma'am".   As a reporter in his class you were writing articles, not editorials.  Your opinion was not to be included in the writing.

The second thing he hammered home was the 5 W's and 1 H concept.  I think he must have said them aloud to us every day in the beginning of class…

I have found that these two items that were drilled into me in that class easily pore over effectively to reporting bugs. 

Reporting the facts only prevents friction between development and testers.  It largely prevents reports that seem to be attacking developers.

The 5 W’s and 1 H, in a simplified context, could look something like this:

1.       Who? – The application/system/product in test

       2.       What? – What feature/component/link/etc.
       3.       Where? – Where is the testing taking place, what is the environment
       4.       Why? – If you think you know what might be causing the bug, add this to the report
       5.       When? – What is the state of the application/system/product when this bug is revealed
       6.       How? – What are the steps to reproduce the bug

Of course this is shown at a very simple level, but when considered during testing, these items are very useful in gathering information that will speed up the time it takes to get the bug addressed. 

Sometimes, testers get caught up in the ability to “break” the application/system product, and forget that the reporting of the bug is more important in getting it fixed.

Here is an example of a fake bug report.  In honor of the newspaper I worked on in high school, I will call the pretend product “The Hitching Post”.  One of its features is the ability to create text documents.  This is the kind of report I have seen go through the bug tracking system when the concepts above have not been considered:

Headline – The application crashes when attempting to save a text document

Steps to Reproduce:

     1.       Open a text document
     2.       Click the Save icon
     3.       The application crashes

When I have seen this type of report, I will send an inquiry for more information.  Usually I will ask questions.  In this example, I would likely ask at least the following:

1.       What OS is the product installed in?

      2.       What version of the product are you testing in?
      3.       What state was the document in?  New, previously saved, edited?
      4.       If the document was edited, what was entered in it?  Illegal characters, font change, number of characters?
      5.       Does this occur when using the Save menu item or shortcut key?
      6.       When the product crashes, is there an error message?  Is the message a product message or a system message?
      7.       Are there any error logs that can be attached to the report?

My belief in writing bug reports is to have development spend little to no time in coming to see me or talk to me – about the bug reports, that is J  I find that applying these concepts to the report have caused me to be more focused on gathering as much information as I can.