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.
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.
2 comments ::
link
