Introduction to the First Law of SQA: Observation
Posted on 2008-Aug-9 at 12:52
Preface: I'm not the best when it comes to writing - I am so out of practice; so please understand that these are still working theories that I am trying to find the clearest way to explain them.
Also I want to upfront apologize if anyone gets offended. I am not ditzing offshore QA teams, because I have proven with the right type of training and mentoring you can take the what is worse dynamics issue/problems out there within an offshore team and turn those folks into amazing test engineers. (mind you I learned another lesson after that, the lesson of lack of loyality but thats a different problem)
Normally, we do not so much look at things as overlook them. — Alan Watts.
Observation: There are numerous levels, actions, considerations to what entails the ability to observe. However, I summed it up:
Law One: Observation is to
* be -in the now-
* to utilize all senses to record the event as it transpires without altering the event.
It sounds simple, but it is not. And for me, while I have spent now several years perfecting my observation skills, I still sometimes am too hasty and make decisions about my bug before I finish observing it, which does lead me to paths of the odd and unusual.
We are creatures that observation is not only a basic function of our existance and survival - to record through the senses events that happen from moment to moment, but it is also a learned ability, because we are all brought up to 'see and feel things differently'.
Ruling out those with special abilities (photographic memory, eidetic memory, high awareness sensativity), most of us go through life in a state of unawareness. We are taught to - ignore the homeless, look past the helpless, not to stare, not to take too deep of a look. We are taught to kick the tires, check under the hood but don't look TOO deep. We're told - Leave well enough alone, don't go looking for trouble, nothing is perfect.
We do drive by comparrisions, make first impression conclusions and decisions. We use soundbites, google now for getting observations, shortcutting down as fast as possible to achieve the task of saving a buck.
And that is JUST one aspect of the US Culture of thinking when it comes to observation.
Now, add country cultures of 1000s of years old, viewpoints on how to observe, taboos as engrained into the person that they come so natural as breathing, you can get where folks do not possess the ability to truly capture an event without quickly forming an opinion from one extreme, to ignoring it on the other extreme.
Now I know the law sounds so esoteric that one can question the validity of how the **** is this going to actually make a difference in testing. - And granted - Be in the moment - part is not my creation but one of the foundations of Zen Buddhism, but the fact is, even 10% growth in awareness in how to Observe increases the effectiveness of bug reports ALONE.
Math is simple:
Bug spotted or observed - 10 minutes
Bug report written poorly because of lack of good observation - 30 minutes
Bug report comes in - scrubbed (remember scrub only reads and determines direction) - 10 minutes
Developer tries to reproduce the problem - 30 minutes
Bug goes back to reporter for clarification
Repeat - until someone ignores or steps are able to be reproduced.
Factor in number of times this happens, time delay in response, number of -people- between the Reporter to the developer that may have to get involved.
There are enough reports I can direct you to, for statistics on bug cost but the average cost of a bug from offshore teams is not pretty. And the offshore salaries are expect to match US salaries by 2010 by several reports I have read.
You're probably jumping ahead and saying to yourself - this is a really a duplication issue...
No...
it's an observation issue - because something was missed, overlook, unaware of in the observation so one could duplicate it.
--- Okay --- so great nice law, but how the heck do you actually do something about it.... (Yes I am my own best cynic)
The biggest challenge I had with my first offshore team with working with Observation was understanding their culture - in a thinking process way.
For example one culture I work with;
No meant yes, Yes meant Maybe, and no questions meant not wanting to look ignorant.
But there was a lot more than just these few tidbits I learned quickly. Group dynamics play a part of the picture when it comes to observation (everyone has to agree they saw the same thing before one files the bug) Soon I became overwhelmed with data about how my offshore team thought/worked/interacted, which forced me to examine our onshore team's methods of thinking/working/interacting.
So I had to figure a way to catalog and organize what I was learning in a way that I could determine how to affectively introduce the changes necessary to teach and mentor the team into learning new ways to observe.
- Next post - What questions worked, what questions didn't work. Re-thinking what it means to observe.
Also I want to upfront apologize if anyone gets offended. I am not ditzing offshore QA teams, because I have proven with the right type of training and mentoring you can take the what is worse dynamics issue/problems out there within an offshore team and turn those folks into amazing test engineers. (mind you I learned another lesson after that, the lesson of lack of loyality but thats a different problem)
Normally, we do not so much look at things as overlook them. — Alan Watts.
Observation: There are numerous levels, actions, considerations to what entails the ability to observe. However, I summed it up:
Law One: Observation is to
* be -in the now-
* to utilize all senses to record the event as it transpires without altering the event.
It sounds simple, but it is not. And for me, while I have spent now several years perfecting my observation skills, I still sometimes am too hasty and make decisions about my bug before I finish observing it, which does lead me to paths of the odd and unusual.
We are creatures that observation is not only a basic function of our existance and survival - to record through the senses events that happen from moment to moment, but it is also a learned ability, because we are all brought up to 'see and feel things differently'.
Ruling out those with special abilities (photographic memory, eidetic memory, high awareness sensativity), most of us go through life in a state of unawareness. We are taught to - ignore the homeless, look past the helpless, not to stare, not to take too deep of a look. We are taught to kick the tires, check under the hood but don't look TOO deep. We're told - Leave well enough alone, don't go looking for trouble, nothing is perfect.
We do drive by comparrisions, make first impression conclusions and decisions. We use soundbites, google now for getting observations, shortcutting down as fast as possible to achieve the task of saving a buck.
And that is JUST one aspect of the US Culture of thinking when it comes to observation.
Now, add country cultures of 1000s of years old, viewpoints on how to observe, taboos as engrained into the person that they come so natural as breathing, you can get where folks do not possess the ability to truly capture an event without quickly forming an opinion from one extreme, to ignoring it on the other extreme.
Now I know the law sounds so esoteric that one can question the validity of how the **** is this going to actually make a difference in testing. - And granted - Be in the moment - part is not my creation but one of the foundations of Zen Buddhism, but the fact is, even 10% growth in awareness in how to Observe increases the effectiveness of bug reports ALONE.
Math is simple:
Bug spotted or observed - 10 minutes
Bug report written poorly because of lack of good observation - 30 minutes
Bug report comes in - scrubbed (remember scrub only reads and determines direction) - 10 minutes
Developer tries to reproduce the problem - 30 minutes
Bug goes back to reporter for clarification
Repeat - until someone ignores or steps are able to be reproduced.
Factor in number of times this happens, time delay in response, number of -people- between the Reporter to the developer that may have to get involved.
There are enough reports I can direct you to, for statistics on bug cost but the average cost of a bug from offshore teams is not pretty. And the offshore salaries are expect to match US salaries by 2010 by several reports I have read.
You're probably jumping ahead and saying to yourself - this is a really a duplication issue...
No...
it's an observation issue - because something was missed, overlook, unaware of in the observation so one could duplicate it.
--- Okay --- so great nice law, but how the heck do you actually do something about it.... (Yes I am my own best cynic)
The biggest challenge I had with my first offshore team with working with Observation was understanding their culture - in a thinking process way.
For example one culture I work with;
No meant yes, Yes meant Maybe, and no questions meant not wanting to look ignorant.
But there was a lot more than just these few tidbits I learned quickly. Group dynamics play a part of the picture when it comes to observation (everyone has to agree they saw the same thing before one files the bug) Soon I became overwhelmed with data about how my offshore team thought/worked/interacted, which forced me to examine our onshore team's methods of thinking/working/interacting.
So I had to figure a way to catalog and organize what I was learning in a way that I could determine how to affectively introduce the changes necessary to teach and mentor the team into learning new ways to observe.
- Next post - What questions worked, what questions didn't work. Re-thinking what it means to observe.
0 comments ::
link
