I've edited a whole lot of books, articles, help files, websites, and white papers about technology. I've seen countless products come and go and I've been on plenty of teams building apps or software. At the end of the day, there's one thing I'm sure of: Everything needs to be tested before it's sent out the door, whether it's the software, the device, or the words. Not only will your product (or article, etc.) be better, but you'll grow, too.
Editing text is different from testing software, but it's the same principle. You want users to effortlessly read the words and use the product. You need to know if the dialog box you see as the gateway to your product contains a mystifying set of text boxes or if the search function produces random results. You don't want people to struggle to use your product; you want a clear flow of information or function, and clear help files in case they get stuck.
I once worked at ZD Labs, which supported all 12 of Ziff-Davis Publishing's tech magazines. Our group took hardware and software and did our best to break it. We built devices that held laptops precariously over various surfaces and dropped them repeatedly from a specific and controlled height. We wired keyboards and spilled various substances (soda, water, coffee, etc.) on them until they failed, and measured how much electricity zapped the keyboard and whether it went with a whimper or a bang. We did the opposite of what every well-intentioned instruction told us to do. We had a Faraday Cage to deliberately electrocute computers and a completely soundproof room where we could measure how loud that fan keeping your hard drive cool really was or how much noise a room full of mainframes made. In short, we had a whole lot of fun.
The object wasn't really to have fun but to use the product in the worst possible way in a controlled environment so that the various tragedies could be measured. We barely read, entirely skipped, or obstinately misinterpreted instructions. We researched statistics - how many seated users knocked a laptop off their laps or dropped one while running through an airport. We even had a rubber finger on a stick that poked the same ke, around the clock for weeks on end until the key broke.
W studied whether a non-technical person could figure out how to use a piece of software. To perform such a test, I built a database using FoxPro that tracked the timecards and contract lengths for ZD Labs' team of freelancers. I enjoyed it enough that I next volunteered to build a much more involved database using an Oracle product (with a lot of help) to set up a software and literature library at the lab.
The whole reason for ZD Labs' existence was to find out whether products kept the promises on their boxes, and to see if a reasonable amount of use or abuse might break them. We set benchmarks to compare similar products or functions, and we brought in freelancers with widely varied skill sets to see how much knowledge was needed to succeed - or fail. Our purpose wasn't to help the manufacturers, although that was probably a result. We were trying to inform magazine readers so they could make intelligent purchases and use the products in an advantageous way.
No matter how brilliant you are as a software designer, you need someone to be your first user who can provide the kind of feedback that helps you deliver a great product before it goes public. It's the same if you're writing about technology or providing the supporting documents that ship with the product. You can use (or reread) your work again and again, but you still know what the original intention was, and logical lapses won't jump out at you the way they would to someone who's not using your brain. You need someone to intentionally break your product and then give you feedback.
What if your first user (or editor) has different taste or disagrees with your design? What if they don't understand your goal, or worse, what if they inject their own ideas into your work? That's the second half of having your work tested or edited. As important as it is to get feedback, it's just as important to know how to respond to it.
Let's say that you build an app that measures hiking paths. You track whether the paths are also suitable for horses, bicycles, or small motor vehicles, you've got elevation change, and you track distance and give a letter grade for difficulty. Your beta user wants a bigger picture - parking availability, running and hiking clubs that use the park, handicapped access, bathroom and water availability, and so forth.
Those are good ideas, of course, but perhaps that's not the app you're building. Or perhaps those are on the wish list (backlog) for V2, but you've got a deadline to meet. It's your job to figure out whether the app's users need those things or whether they're just bells and whistles. You might have to do a cost analysis to make this decision or maybe you already know the right thing to do.
Whether you rush to add those features or not, it's important to consider that your tester (editor) won't be the only person to have those thoughts. They're merely the first. You need to consider the cost of delivering something that might easily be seen as incomplete, even if you disagree.
I've seen more unpolished text than software as an editor, but it works the same way. If you're writing the help files or UI, or even a nice article, it's important that your first reader understands exactly what you mean. Instructions are not the time to get fancy or play with hyperbole or other literary devices. Oh, you're welcome to be humorous, clever, or even charming (if you are those things), but not to the point that the reader thinks about YOU rather than the product.
A good tester or editor will know what you meant and be able to help you produce the result that you had in mind. You might even be a pretty good tester or editor yourself. But there's a danger in thinking that you can be your own tester or editor. You know that old adage, “The lawyer who represents himself has a fool for a client,” right?
A good dev or writer can certainly make a decent pass at his own work, tweaking here and tidying there. And that should happen, every time, whether you're writing code or text. But it's a very bad idea to deliver a product that only you have tested or edited.
It's the weird interpretations other people make that allow those flashes of inspiration and insight and make your work better. That's how you grow. You'll never be finished growing if you're good at what you do.
Post Script: One of my editor friends suggested a Dr. Dobb's Journal frequent blogger's posts about testing. The Dr. Dobb's site went dark in 2014, but the articles, and many new ones by Michael Hunter, are available here: http://www.thebraidytester.com/. I've got more than a hundred articles on writing for technical people on my website, at www.MelanieSpiller.com.
