I was putting together a demo on an application today and came across a bug. It was something that, when a new feature was developed, was overlooked. I let one of the testers know, and for a second I felt what I thought was a sick sense of pleasure at finding it. I thought that tester was rubbing off on me, since the team teases him about finding joy in locating bugs. If I’m happy to find a bug, am I supposed to be a quality assurance engineer?

I decided after a bit of thought that what I felt was satisfaction from contributing. It was a fairly important bug to find, and it just happened to be overlooked by the developer (which means it may have also been overlooked by the designer), and the QA engineer’s test cases didn’t dig that deep.

Without meaning to harp on a point, this reinforces a reason technical communicators are important. This isn’t the only time that my approach to functionality, trying to use it as the users would, has uncovered things that QA didn’t. The QA team is invaluable to me because they know what the functionality is supposed to do and when a certain occurrence is a bug. I talk to the QA lead on that project quite a bit, and he’s a great resource.

But when it comes to assuring the quality of a product, it’s a great advantage to have someone who thinks like the user and exercises the product like one. It’s one of those specifically identifiable areas in which the technical communicator’s role adds value to the project.

Related posts (auto-generated):

  1. Important Players in the Content Review Game
  2. Four More Reasons Your Company Needs Technical Communicators
  3. A Bug-Fix Cycle at Project End Is Good for Everyone
  4. Does Your SME Know What a SME Is?
  5. Team Documentation Design Reviews