In the project portfolio where I work, we have several applications in maintenance mode. A number of developers and testers, some previously assigned to dev projects and others relatively new, may work on bugs from any application at any time, and most aren’t familiar with the applications yet.

My cubicle is next to that of Matt, one of the testers. One day he was trying to follow instructions in some test cases and hit a wall because of lack of detail. He called over Nathan, another tester in a neighboring cube. They launched into a discussion of how much detail should be included in test cases.

Matt’s problem was steps that assumed prior knowledge. It would be a general step like “Create a payment to a landlord.” Well, how do I do that? he wondered. A number of steps are involved in creating a payment, and he didn’t know what they were. The test case was obviously written for someone with a certain level of knowledge about the application. Matt needed more detailed steps.

› Continue reading…

Bookmark It

Hide Sites

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.

Bookmark It

Hide Sites

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.

Bookmark It

Hide Sites

One of the things that makes quality documentation on a product is a review process. I think many technical communicators would agree with me, however, that sometimes the process becomes more cumbersome than beneficial. The more people involved, the harder it is to meet deadlines.

While I’m in favor of a limited review process, I think including four certain types of people will maximize the results. I’m not recommending a particular order here.

› Continue reading…

Bookmark It

Hide Sites

We have a customized flavor of Agile development, and today as I was talking to one of the program managers about the next few cycles of work in a particular project, he said that the work in the last cycle or two was not yet defined. That’s fine; at least in our version of Agile, the work that was defined generally at the beginning is solidified as we go. Development is planned on an iteration-by-iteration (or sprint-by-sprint in some vocabularies) basis and more broadly on a cycle-by-cycle basis. A cycle contains several iterations of work, and the idea is to have a body of code that can be released to and used by the customer at the end of the cycle. The interaction designers prototype at least one cycle ahead of development.

The manager hopes that most of the new development work will be done at the end of the second-to-last cycle. As he talked, I got a little idea: What if the last cycle of an Agile project were reserved for bug fixes? We have hardening periods before the release for fixing bugs and for the testers to make sure they’ve exercised and proven the functionality that was developed at the end of the cycle. But what about an overall hardening cycle for the bugs that haven’t yet been addressed throughout the entire project?

This would benefit the team and the customer, but I wouldn’t be talking about this if I didn’t think it could benefit me, the technical communicator.

› Continue reading…

Bookmark It

Hide Sites

If you’re in the business of developing and selling products that are in any way technical in nature, you probably spend most of your time planning or implementing specifications, development and release schedules, budgets, and engineering strategies. Or you may be directly involved in the day-to-day development and testing of the product. Whatever your role, the product is the most important thing. After all, if there’s no product, there’s no business.

In all of the things you have to think about, have you thought about bringing a technical communicator into your team? The realm of technical communication involves many job types, but in this particular context, I’m talking about a technical communicator who produces documentation that is intended to be distributed to the product’s end users. That documentation may take the form of online help or other Web documents or printed documents. Sure, a tech communicator may be another body taking up project budget, but here are seven reasons you should work a technical communication team member into your budget and project plan.

› Continue reading…

Bookmark It

Hide Sites