Let’s say you are a college student taking journalism and your assignment is to write a review of some computing product or service. What do you do? To get things started, here are a few suggestions from someone who has been writing such reviews for more than 20 years, publishing hundreds of them in dozens of IT trade publications and Web sites.

Make sure you have the most up-to-date product version. This seems obvious, but there are many download sites that don’t make it easy for you to determine this. Make sure you are testing a shipping version too: the differences these days between beta and final versions are very blurry (remember Gmail was in “beta” for several years).  And if you are testing some Web service, realize that the code that you test today will change tomorrow, so it is important to check back when you finish review (if some time has elapsed) to make sure that you cover the new features that were recently added. I know, the Web makes for a moving target.

Go to the vendor’s Web site, collect information such as system requirements (which version of Windows, with what Service Pack and what version of .Net Framework and Internet Explorer) and make sure you have a PC that can run the software you downloaded or work with the particular hardware.  If you are testing a network product, make sure you have at least a server and a client or two for your tests. Also find the current pricing information (this is usually the hardest thing to discover), and call the PR contact listed for the company (if indeed it is listed) and tell them you are going to be reviewing the product. You could ask them for a special tech support engineer to resolve any issues, depending on the product and your own level of comfort.

Some professional reviewers shun special tech support, I find it useful especially if you are stuck with a problem that is entirely of your own ignorance and you are trying to resolve the issue and get your review finished.

Don’t write about your installation experience. Even if it was onerous, your readers don’t care. They want to know what the product does. Just get straight into the review. If you must carp about the install, write the graf and then delete it before your final edit to get it out of your system.

Give us a nut graf that sets expectations of who uses what and why. See the first graf of this screed as an example: I tell you who should read this piece and why I am qualified to write it.Most of the times this is the second graf of your review: “Microsoft’s new cloud-based thing is aimed at engineers who can understand how to configure routers in their sleep, but isn’t yet ready for the general IT population.”

Understand the context of where the product fits into your reader’s computing ecosystem. If it is a cloud-based Web application, does anyone use similar premises-based applications of equivalent functionality? Why or why not? If you don’t know the context, this would be a good time to talk to a few IT folks to get some idea of how they intend to use the product, or drawbacks in similar products that they are trying to avoid.

What breaks or doesn’t work when you try to use a Mac or Linux machine? Not everyone uses Windows PCs, you know. Dealing with a mixture of endpoints is part of the challenge of any modern IT department. Same is true for a variety of browsers. Make sure your test plan is rich enough to include these variations.

When you get some unexpected result, it is polite to call the vendor and let them know. It could be something you did. Or didn’t do. They could have a fix coming for this situation, something you might want to tell your readers about. Or you could have found a real honest-to-goodness bug. It happens.

Take copious screenshots for your own reference, as well as for ultimate publication. I prefer to use TIFFs because you can preserve higher-resolution screens. I then create a private photo album on Picasa or Flickr that I upload the screens to and link in my article so my editor can pick the ones that s/he likes. Having this record can be useful if you are going to get paid to write another article for a different publication down the road, because you won’t have to go back and try to re-create your test bed.  Windows 7 (Snap) and Mac OS (Grab) come with built-in utilities to take screenshots. Oh, and include captions on all of your screenshots too.

Look at the previous version, or at least the press release, to understand what is new and shiny and different about the current version. What did the vendor add, why did they add it, and what does that mean for users of the legacy product?

Look at the competition too. If you don’t know which products are competitors, you can ask your friendly vendor PR person. If the vendor tells you that they have no competitors (they often like to say that) and you know this not to be the case, don’t be afraid to call them out on it.

If you don’t know how to use desktop virtualization technologies, now is the time to learn. Virtual machine products such as VMware have made the product reviewer’s job a lot easier. When I began in this business, I had a room full of PCs that were setup for different situations. Now I have a hard disk filled with VMs of different operating systems, and when it is time to test something, I can make a copy from my clean master and not have to worry about reinstalling the OS if something goes south.

Email your PR contact when the review is published. These days, almost everyone has set up Google alerts but you want to show that you care. Thank them for their help, even if they were less than forthcoming. You want to build up a relationship with these folks. Don’t be afraid to enter into a dialogue with the vendor to explain your point of view and take the time to listen to where they think you missed the boat.

Good luck with your reviews and feel free to share here some of your own tips.

For a more detailed missive on how PR people should deal with the press from the press’ perspective, see the very excellent “Care and Feeding of the Press” by Esther Schindler here.