Re: Design specs (Was: Design Methodology for GUIdevelopment)

29 Jul 2004 - 7:29am
10 years ago
1 reply
553 reads
pabini
2004

Hi Jim

> "QE" stands for "Quality Engineering".

***PGP I figured as much. :-)

It used to be know largely as
> "Quality Assurance", and the Microsoft-approved term seems to be
> "Test Engineer". (Which to me minimizes/denigrates the discipline,
> but if you want to job search for the role, you use what the
> 800-pound gorilla uses or you lose 50-90% of the hits.)

***PGP I appreciate your remarks, because my husband works in your field.
This information about shifting titles will be helpful when he searches for
work.

> In my case, I've specialized over the years in "User Interface
> Testing"....

***PGP Good for you. I'm of the opinion that the kind of testing you do
involves just as much know-how as white box testing does--just of a
different kind. You're focusing on the more subtle issues of user
interactions and usability, while white box testers (let's denigrate them a
teeny bit for a change ;-) ) focus more on programming. Both kinds of
testing are useful for very different reasons.

I ... worked on FrameMaker (Frame/Adobe.

***PGP I write my specs in FrameMaker, for easy conversion to PDF, and have
been using FrameMaker since version 1.0.

> My testing goes most smoothly and has the best impact when I have the
> most and the most accurate info. Testing components in isolation
> isn't as effective as testing them as part of a larger package, where
> feature interactions can be dealt with as well.

***PGP Amen!

(Although I largely
> focus on UI testing, which many people would expect to result in
> mostly either fuzzy usability complaints or miniscule layout bugs --
> the sort which mostly never get addressed in the at-hand product
> cycle -- by working in the larger package, I tend to hit the same
> percentage of severe and crasher bugs as other testers, as well as
> all the small stuff.)

***PGP The same is true for my husband, who does the same kind of testing
you do. I know many people who do this kind of work. Many are now out of
work. Can you tell me what companies you know of that still value black-box
testing? Many companies don't and focus on white-box testing. I think people
who work in your role can be very helpful in ensuring that products are
implemented to spec.

> The standard Product Life Cycle generally puts Testing very late in
> the process, but since the best testing is done with full
> information, QE having input earlier in the process -- during spec
> review, and even before -- is massively useful. If nothing else, it
> lets us understand why certain decisions were made, so we don't have
> to fight with such issues when we actually get the software to test.
> But usually, it allows us to give feedback on how we will test a
> feature, allowing the UI team and the Dev team to recognize
> weaknesses before coding them in stone.

***PGP It's so important to have cross-functional teams and have everyone
involved from the early stages of a project. I've always had QE/QA review my
specs.

> An ideal spec to test from would include reasonably accurate
> screenshot and mockups,

***PGP Here I'll fuss a bit and say that these aren't screen shots, they're
screen drawings and a lot harder to create than going snap. ;-) They are
essential content for a spec.

details about each control's behavior
***PGP Yep. And function.
notes on shortcuts and hidden features,
***PGP Absolutely.

discussion of expected feature
> interactions and user workflows
***PGP Yes. I call the latter usage scenarios. They document user
interactions step by step.

and selected minutiae about
> usability decisions inherent in the presentation (why bottom rather
> than center aligned, like in the last release; why gray for that
> dialog when all other product dialogs are blue; why are things in
> this list ordered as they are).
***PGP Documenting such decisions is very important to their acceptance. For
feature-related changes, I usually do this in summary in the introduction to
a spec, as well as in sections about specific features. I document visual
design decisions in guidelines documents and new interaction design models
in conceptual model specs.

The better the detail, the less
> stuff we have to assume and the better we can focus our testing.

***PGP Absolutely. :-)

Pabini
________________________________________

Pabini Gabriel-Petit
Principal & User Experience Architect
Spirit Softworks
www.spiritsoftworks.com

Comments

29 Jul 2004 - 12:25pm
cfmdesigns
2004

Pabini Gabriel-Petit <pabini at earthlink.net> writes:

> > In my case, I've specialized over the years in "User Interface
>> Testing"....
>
>***PGP Good for you. I'm of the opinion that the kind of testing you do
>involves just as much know-how as white box testing does--just of a
>different kind. You're focusing on the more subtle issues of user
>interactions and usability, while white box testers (let's denigrate them a
>teeny bit for a change ;-) ) focus more on programming. Both kinds of
>testing are useful for very different reasons.

Now if we can just convince the people who need to pigeonhole people
into Radford classes. If I don't do scripting, then I'm not a
white-box tester, which means I'm in this track of descriptions with
this (lower) salary range.

>***PGP The same is true for my husband, who does the same kind of testing
>you do. I know many people who do this kind of work. Many are now out of
>work. Can you tell me what companies you know of that still value black-box
>testing? Many companies don't and focus on white-box testing. I think people
>who work in your role can be very helpful in ensuring that products are
>implemented to spec.

There really aren't many, so far as I can tell. The numbers-people
prefer the quantification which comes with white-box testing: we have
x-hundred automated test cases covering y-percent of the code base.

There's also a tendency to see QE as a stopover in the high-tech
career path. It's a starting place for junior developers. It's a
step-out for people in Tech Support. It's an "in" to high tech for
tech-savvy folks from backgrounds in music and art. It's a path into
management, or program management. But it's *not* a career path of
its own, or so the thinking goes.

The last round of interviews I did, I got questions very much like
"So you've got 10 years doing QE, huh? Why haven't you moved into
Management [or Development]?" Most companies couldn't imagine that I
would want to stay doing QE.

> > An ideal spec to test from would include reasonably accurate
>> screenshot and mockups,
>
>***PGP Here I'll fuss a bit and say that these aren't screen shots, they're
>screen drawings and a lot harder to create than going snap. ;-) They are
>essential content for a spec.

"Screenshot" is a bit inaccurate, yes. Reasonably accurate mockups
which look like real dialogs and screen layouts and such, if you will.

On my current project, our initial black box test plans were informed
by very early mockups done for "what features would you want in this
product" surveys. We didn't have semi-valid mockups (or text specs)
of the real stuff for months. As a result, our initial test plans
were based on our guesses of what the product would do from those
invalid pieces of info, and we ended up having to fight those
assumptions back later on.

We wasted time and the mental effort needed to comprehend the product
because the info we were given was invalid, and known to be so, but
its invalidity was not transmitted to us. (Once burned, twice shy,
though. We'll know better next time. Maybe.)

> > discussion of expected feature
> > interactions and user workflows
>***PGP Yes. I call the latter usage scenarios. They document user
>interactions step by step.

They seem to be the hardest things to get into the specs. They tend
to live in marketing documents rather than engineering specs, but not
in MRDs or other docs which are available to the entire team.
Workflow info on the current rpoject has had to be guessed at based
on incomplete knowledge of semi-competing products. Thank god for
the marketing and QE people both being in the UI spec reviews, or
some of that info would never get from them to us, and we're the ones
who have to test what they want the product to do!
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at adobe.com
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 07/20)

Syndicate content Get the feed