Friday, June 6, 2008

Anticipation

There are several qualities that make for a really good QA engineer:
  • ability to design a test that provides interesting information
  • a dogged desire to track down the little niggling oddities (that often lead to really deep bugs)
  • well-developed, if informal, systems thinking
  • ability to distill a lot of information into clear and concise descriptions
These are all what I think of as product-oriented abilities. They are the mental tools that allow a QA engineer to approach a system, no matter how opaque, and develop a deep understanding of that product (or tool or application or whatever you call your thing under test) and its reactions to internal and external influences.

But the one thing that really sets a QA engineer (or any engineer, I suspect) apart has nothing to do with the product. It has everything to do with the human organization. And that one thing is anticipation.

The ability to anticipate the needs of the human organization is what makes a good QA engineer great. Many of these are not large changes; they're the little things that make the day flow more smoothly. For example:
  • Knowing that the developer has a standup at noon and will want to know the results of last night's automated tests, anticipation says the QA engineer should look at them enough to offer a summary by about 11:30.
  • Knowing that a big client is preparing for go live in a week, the QA engineer should set up a similarly-configured system in order to be prepared for questions and issues that arise as the system goes live.
  • Understanding that a problem at one client will inevitably lead to the question: "will this affect other clients?" and taking the characterization of the problem to other client scenarios before being asked.
So ask yourself not just "what do they want", but "what will they want next". That's what will tip you over the edge from scrambling to keep up to that corporate zen state called being proactive.

No comments:

Post a Comment