TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
The QA of textual bugs. A TW can really shine by giving the SW labels a good read. Amazing inconsistencies and paradox can surface in field names, menu names, commands in menus, names of radio buttons, and so on.
Get this: one shop had chosen "Format" as a product name. There was a 1st level menu called Format (?!) in that Format app; among its commands: Format. A 2nd-level menu under another 1st-level menu held a Format command. And the App was used to format code. Add a text input utility that had its own "Format" menu. The developers couldn't / wouldn't contemplate that maybe, this would make the documentation confusing: "To format, run Format; select the Format command in the Format menu ... Ugh; semantics can be a tough gig. You can make a case for QA work by reviewing error messages for misleading or incomprehensible text. I usually get the attention of developers and localization with a comment like: "Message 103 is not English." QA usually appreciate TWs who take on the task of spotting typos, inconsistencies and misleading semantics in text, and improving the usability of a product.
Yves Jeaurond
Chris Borokowski <athloi -at- yahoo -dot- com> a écrit :
My only gripe with QA is that generally it isn't
rigorous enough. At this point, even relatively simple
software or hardware is going to be interacting with
so much stuff - OS, peripherals, other software - that
not testing it would be suicidal in my view. The QA
can be informal. At some shops, the developers and
writers and managers are an informal QA department who
use the heck out of the software in a desperate
attempt to find all glitches before it ships. The best
QA ever is using software for a real-life project and
watching the conflicts that arise. QA can also
influence interface and operation of the software,
such as eliminating unnecessarily boring tasks. This
is one area where a good tech writer can become a user
advocate.
--- Joanne Wittenbrook
wrote:
> Well you can't see a problem that doesn't happen.
> So you can't really say what difference the QA
> makes.
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as jingting -at- rogers -dot- com -dot-
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
