Re: Design specs (Was: Design Methodology for GUIdevelopment)
29 Jul 2004 - 7:29am
10 years ago
> "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
> 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.
(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
> 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,
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.