I’ve been in a lightning mode this week, working on a small project that is really an enhancement to an existing application. This enhancement is being built by two developers and tested by one QA engineer. I just started this week on adding to the existing help and am hitting it hard until I get it done.

I started out with some questions to our stakeholder about the business process, and as I’m going through the new part of the app, I’m asking questions of the tester.

I’m doing something else, though. I’ve uncovered a couple of bugs. It turned out that with one of them, what we thought was the bug was actually a symptom of the real bug.

I’ve said before that technical communicators help with the QA effort just by using the product. This is another argument for getting involved early in a project: If the development is nearly done and you uncover some bugs, less time is available for fixing them before the launch.

In this case, it wasn’t as critical because of the size of the project, but the release is still only a couple of weeks from now. I really couldn’t have gotten involved and started my documentation much earlier. Still, the earlier the technical communicator gets into the project in general, the fewer bugs will make it through to production.

Related posts (auto-generated):

  1. A Bug-Fix Cycle at Project End Is Good for Everyone
  2. The Technical Communicator Getting Involved in User Forums
  3. Building from Two Sides: Challenges of Writing Documentation Early
  4. Elements in Today's Release Notes
  5. A Team Member with the Heart of a Technical Communicator