Sara Ford - What does it mean to test? | TheChannel9Team

Lwatson
One ugly mug...

One of my first software related jobs was actually as a tester for some POS software aimed at the restaurant industry. I was actually hired out from my position at a local computer store as a set of hands to conduct the testing suite ( Before the days of automation ).

Well lets just say that I had a knack for finding the obscure ways to crash the stuff. I also showed a propensity to document said crashes so completely that the developers could locate their issues a little more easily. Thats ability was what got me offered a full position outside of contract.

It is however a thankless task, they always hate to see you coming...

amg

Very interesting viewpoint...I've been in the ISV industry on and off for quite a few years now...and I've never fostered the feeling that it was ever a "QA vs. Devs" situation. While some dev. folks can get a bit defensive when faults are found in their code most are more than appreciative that the fault was found and are anxious to fix it.

A technique that's always worked well for me to convince dev execs is to layout the business impact of not compensating for the bug... Wink

saraford

Almost always, devs are very appreciative of finding bugs in their code. It's during those buddy tests (ie, doing ad-hoc testing before the developer checks-in) where you find 8 unique crashes in 30 minutes that you find yourself being asked to go away, but in a polite way of course. =)

I think the "us versus them" feeling comes from the nature of the work we do. Our job is to break the dev's code. In my mind, the dev can never write code that I can't find issues with; otherwise, i'm not doing my job. Many times, i've sat looking at a piece of UI or a piece of code thinking, "what am i missing? what am i not testing?" when i stop finding bugs.

I definitely wouldn't say that i'm in conflict with my dev. A tester must be able to work effectively with his/her developer in order to be successful testing the feature. Chris, the dev for window management (the feature i currently own testing), laughed when I showed him this video. he said, "Yep, i can definitely see you saying that." =)

Lwatson
One ugly mug...

Maybe Hate was to strong a word. I always got along just fine with the developers. Its just that you were most always the harbinger of bad news. Its human nature to exude an aura of dred on someone who is always bringing in bad news. On thought of that point perhaps that was one of my own 'Bugs' in that I may have not always gone back to say when an issue had been cleared up. Definately something for me to think about going forwrd...

amg

saraford wrote:
I think the "us versus them" feeling comes from the nature of the work we do. Our job is to break the dev's code. In my mind, the dev can never write code that I can't find issues with; otherwise, i'm not doing my job. Many times, i've sat looking at a piece of UI or a piece of code thinking, "what am i missing? what am i not testing?" when i stop finding bugs.

Nothing wrong with testers or "QA" folks being perfectionists. =) Striving for perfection is usually the best way to achieve quality.

Does your perception of how users will accept a given feature (such as the window mgmt. you're working on now) ever come into play, or, is your testing more black & white? (e.g. it works or it doesn't)

I'm always intrigued by the very specific vertical roles that I perceive many at MS having...as it's such a drastic departure from what I'm personally used to. =)