Oddity
Posted on 2008-Sep-19 at 08:23
Its been a long two months. I have a lot of things I want to talk about but the highest topic is a comparrison I had today
My husband had a stroke in July. So it's been a really eye opener about the medical world. One of the things I have noticed is the dependancy to utilize high technology to do diagnosis.
This led to a conversation I had with someone about how it is mimicing the QA world, of the dependancy for Companies looking for QA engineers - To Automate and not test.
I do believe in being effective and time concious, but I also know that it was a AUTOMATED CAT Scan -that missed my husband's issue because it hadn't been programmed for the type of issue he had.
Point being - Remove the human factor from diagnosis, (in QA especially) you will miss the things you just can't teach a computer to do.
Automation is supposed to be an enhancement, an additional TOOL in the toolbox, not the only or highest tool in the tool box.
I know the next one was supposed to be more about the First law....
Posted on 2008-Aug-9 at 03:58
But I just had to get something off my chest.
Has business swung too far into the Emotional Intelligence pool without really understanding or training their folks how to actually mentor, review and assist folks who still have basic playground problems.
Reason I ask, is one of the things I just finished watching on the Discovery is Cruelty in Children, and thought to myself - It doesn't stop at the playground.
Yet, businesses now promote the 'EQ' as a means of success. Yet, most companies still do not train, teach, or mentor their employees in getting out of the playground way of reviewing and viewing others.
I understand that to succeed today takes a lot more than skills within the expertise you possess. But I don't see a lot to actually change the dynamics
For example how many software developers have learned how to gracefully accept they create bugs and its just a fact. Not a judgment of their talent. Or that people will find problems because software these days is the express checkout in fast and the furious.
How QA engineers (I so love the we must have tact and diplomacy as a skill) have learned how to become more than harbingers of doom and gloom (I kid you not I have heard - 'STOP REPORTING SO MANY BUGS' - a few too many time, mind you sometimes in jest, but sometimes I wonder) Or worse in one of my cases, considered to possess a "can't do" because I was willing to do my job and found so many holes in a product design.
Or managers that don't have the time these days to actually create helpful guides and training material that helps teach people how to collaborate together, share ideas, express views without division.
There still are cliques at work. There still are micro playgrounds at work. There still is the odd kid out who seems to be picked last.
There still are teachers' pets. ......
So many new companies put so much onto the 'It is all about the people' yet they are pushing the bottom line as their driver for success.
Relationships don't make software.
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.
What prompted the 3 laws
Posted on 2008-Aug-9 at 11:08
We've all been asked this numerous times in our career. We've all commented, complained, moan and groan when we have been forced to work with folks who don't get it.
Its that elusive statement 'What do you think is a good Test Engineer' (and any derivation of that statement/question).
For the longest time, I rambled off the tried and true mantra;
High attention to detail
Able to analyze and isolate issues and defects in product
In-depth working knowledge of QA methodologies and practices
Demonstrated ability to write in depth test cases, test plans, test procedures easily.
Solid understanding of Product life-cyle
Able to distill customer requirements into product quality needs.
Have great communication (both written /verbal) skills
Work closely and well with Product team (developers, customer care, product management)
Yady yady yady
And the more senior you were, the more things like automation tools, scripting, even programming in languages became a requirement to determine if you were 'worth your weight'.
It was very rare you saw folks stay as QA Engineers in this field, between always been the last on the food chain, and under appreciated, over worked, and having to deal with telling people their stuff is broken 'nicely and politely' burn out was common. Most jumped into Development once they reached a certain level, or into management.
Then the 'offshore teams' started popping up. Because of costs mostly, QA was one of the first to be sent abroad.
And the new crop of problems arose.
The biggest one was ability to actually test the product, verse- executing cookbook test cases and understanding the complexity and concepts of the cases to truly test, verse execute.
And more so, Software engineers these days coming out of college have very little in actual practical understanding of product life-cycles and testing methodologies that it becomes very clear very quick something needs to be done.
So in 2005 I being on a team that was forced to utilize an off shore team that basically was costing us more in time, energy and resources to manage and maintain than it was worth, started to do a bit of my own 'bug hunt' so to speak about the problem at hand.
Oh, there were the obvious first initial answers that I kept hearing from the team as a whole.
Poor - to un-reproducible bug reports.
Inability to write test cases because they only understood how to verify actual written requirements.
Inability to create user scenarios from product requirements
Inability to think past the actual steps written in the case to create additional test cases about the feature.
Inability to follow instructions
And we had our own flavor of issues
Inability to work directly with the off shore team (they were on a 13 hour difference in time)
Having to work directly through lead to lead which meant the game of TELEPHONE at time (if you have never played telephone, it is the most amusing game of duplication)
Lack of questions being asked of the offshore team for clarification, interaction, involvement.
---I could go on----
It was frustrating everyone on the team. Developers would not even work on bugs coming from the offshore team until at least one QA engineer on this side validated and cleaned up the bug report. The management instigated a weekly call in hopes to foster more active involvement. The individual members of the QA team reached out trying different approaches to address the issue.
Even some of us took Culture courses to help isolate, identify, articulate and create solutions for this.
Then one night, at 2 am - on one of those nights I was sitting at the office working in IM with the Offshore lead about some issue, it dawned on me.
There are only three laws to QA.
Observation
Duplication
Expectation
Simple?
HAHAHAHAHAHAHAHAHAHAHAHA
Not by a long shot.
But that was the answer, and that was the solution.
But it took another two years to work out the theories, the obstacles, the problems and most of all hone it that it can be taught to managers and teams.
Lead us not into tempation....
Posted on 2008-Aug-9 at 10:23
I know what an interesting opening line for a blog. But it is how I feel.
You see I've been one of those Test/SQA engineers that sits in the shadows of the professional community. I may attend a SQA meeting here and there. I may be part of a panel at a Convention, sometimes having standing room only tech nights. I've written technical docs for products I have worked on for tips/tricks and advance techniques. I may even once and a while post something that is about QA or training based on some forum.
But I stay in the shadows. It is comforting. It is safe. Nobody can laugh at you and your ideas if you don't say anything.
Which is weird because when I work, folks call me tenacious and dedicated with conviction. I stand up for bugs, ideas and concepts, within my little cloistered world of the team.
So what prompted me to come out of the shadows?
I was interviewing at a company (who shall remain nameless) and speaking with one of their cheif QA engineers. He's well know in the community. He's well respected and was going to be giving a talk at an upcoming technical convention on SQA. We were having a conversation about ideas, technologies, advancement in the culture and processes of QA. And I casually mentioned about my theories of QA.
After explaining to him my 3 laws, he really thought it was quite unique and even asked to borrow it for his presentation. He asked me why I don't publish my ideas, or at least blog my ideas.
That got me thinking about what is it that keeps me in the shadows about my career.
I've revolutionized other teams with my ideas. I've created new QA processes that have been standardized in very large companies. I've been doing AGILE before it was even called that. I taught brand spanking new interns fresh from college who had NO clue how to be some of the best QA engineers around. I have legacies at companies I have left - even to this day I have heard comments like 'Nobody could replace you, man - the servers have suffered since you left because NOBODY tests like you do, even with your notes, they just don't feel the machines.
Engineering directors have raved about that I am the best QA engineer they have ever seen/worked with. Developers have gone out of their ways to make sure I work on their code.
But......
I feel humbled in the presence of my of my peers because I can't code. I am humbled and more so, feel like a second class citizen because I don't have a CS/CE or any other computer technology related degree.
I stutter - so at times it is hard to understand me
I am very unusual - Most can't believe I am as old as my license says, because I have the gullibility of a 5 year old, and the joy of exploration has not died in me.
I think in three-dimension. I see things in pictures, in connections.
My brain processes faster than I can speak...and sometimes it processes and I don't even realize it has an answer.
I don't believe in politics, bull****, bureaucracy. I can't condense down easily. I believe in technical aptitude and facts.
And I don't do well when I am out of my social class. I feel like the little kid at the grown-ups table at Thanksgiving, unsure of what to say or do and inevitably always manages to say something that truly isn't 'adult'.
But when I am in my game, in my world, where I feel safe I make the difference. I shape and re-define testing methodologies, constantly finding ways of improving, honing, challenging standards to push the barrier of Quality and the ability to test, effectively, efficiently, factually, and conceptually.
So, I decided to come out of my shadow, out of the darkside, the lunatic fringe and at least put my ideas down so others can use them, abuse them, do whatever they want to them, but its no longer just in my head or my teams that can benefit from me.
|
|
|
