Writing isn't easy--let me just make that perfectly clear. Anyone who tells you that writing is easy is either lying to you or doesn't understand what quality writing entails. Writing requires careful thought, a great deal of planning, constant review of your work-in-progress, and a great deal of skill, which can only be gained through experience and practice. Sounds a lot like a description of software testing, doesn't it? The truth is that there are a number of similarities between quality writing and quality software testing, and skills in one discipline can help you a great deal in the other, both directly and indirectly. While written documents may or may not be required within your test team, the process of writing can be extremely beneficial in itself.
As software test professionals, you're well aware that terms like "quality" and "good" are often considered loaded weapons in our industry. So it's important to explain now what I mean by "quality writing."
What Is Quality Writing?
Quality writing is clear, concise, well-thought-out, and grammatically and syntactically correct. It conveys the author's thoughts to the intended audience without additional, unnecessary information. When someone reads a document that has been written well, he or she is able to quickly and easily ascertain the author's purpose for writing the document and what key points or issues the author covered.
There are two important elements in quality writing- the way it is written and what is written. The first section of this article covers the process, or "way," of writing. The second section discusses the "what" of writing. There are particular benefits from each element on its own, but your writing will be most effective if you pay attention to both.
Benefits of the Writing Process
Even the simplest forms of writing can prove invaluable in the testing process. If you're beginning a test effort, take any documentation you may be lucky enough to receive from the development team and re-write the key points in your own words. If you're able to transform a requirements document into a hand-written, bulleted list of items, you have a pretty good understanding of what the system is supposed to do. This type of list also helps you understand your particular role within the test effort since it allows you to see the features you are responsible for and the ways in which they interact with the rest of the system.
People cannot write well about things they are unsure of or do not understand. Therefore, if you find yourself unable to "translate" a requirement or feature, the developer may be fuzzy on the issue as well. This kind of inability to write about an area of the system under test should raise an immediate red flag. If you don't understand it, how can you test it? And if the developer is unclear about it, you've just found a potential nest of bugs.
Even if you don't receive any documentation on the system you're testing, coming up with a list of key requirements or features on your own can be extremely helpful. By writing the details of the system, you can come up with a quick overview of the system's functionality. You can also quickly realize where there may be "holes" in the scope of your test coverage. Whether you use a formally documented test plan with detailed test case steps or take more of an exploratory approach to testing, the benefits are the same. By writing your test plans, formally or informally, and comparing them to the overview of the system, you can see where additional coverage is needed.
The process of writing your test plan can reveal other types of "holes"-those in the system itself. You are more likely to catch problem areas early, which may warrant further development efforts, as well as areas that simply need clarification in the documentation.
These holes may appear immediately while you're writing your plan, but they often are much more apparent after the writing is complete. Give yourself a day or two away from what you've written, and when you re-read it, anything that doesn't fit or is missing will jump out at you.
The effort of writing your test plan will often foster increased interpersonal communication as well. Whether you're clarifying an item in the system's documentation or you're asking for suggestions on test data, chances are