Re: Design specs (Was: Design Methodology for GUI development)

28 Jul 2004 - 12:04pm
911 reads

Elizabeth Bacon <eb at> writes:

>What is QE, exactly?

Well, there's a big old Pandora's Box for you. <grin>

"QE" stands for "Quality Engineering". 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.)

(I'm sure there could be the same sort of "what to call it" arguments
as with Interaction Architect/User Experience Designer/whatchagummi.)

QE usually breaks down into "black box" and "white box" testing,
which are roughly manual, through-the-UI testing, and automated or
API testing.

In my case, I've specialized over the years in "User Interface
Testing" (whatever that might mean; as expected, it's bound to be
broader than any easy definition). I started with an MS in Software
Engineering, then worked on FrameMaker (Frame/Adobe), the SoftBook
Reader/eBook (SoftBook Press/Gemstar), Version Cue (Adobe), and other
stuff. UI Testing is usually under "black box", and since all three
terms (UI, testing, black box) are often seen as lesser or inferior,
many people I work with have little concept of just what it involves.

>But I have another question: what is the ideal kind of interaction design
>spec to receive, speaking from a QE/development/testing perspective? (Just
>don't tell me it's a Use Case....)

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. (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.)

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.

An ideal spec to test from would include reasonably accurate
screenshot and mockups, details about each control's behavior, notes
on shortcuts and hidden features, discussion of expected feature
interactions and user workflows, 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). The better the detail, the less
stuff we have to assume and the better we can focus our testing.

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA jdrew at (Update: 07/20)

Syndicate content Get the feed