Posts in Books
Technical Writing
Over the weekend I read the book Spring Into Technical Writing for Engineers and Scientists by Barry Rosenberg. It's lead me to a couple of realizations:


  1. I don't write as well as I'd like to.

  2. I don't speak as well as I'd like to (I really already knew this - this book just confirmed it).

  3. I don't spend enough time focusing on my writing and speaking.



The following is a quick overview of the book. The short version is that I would recommend this book to anyone in this field. If you are a tester or developer, pick up a copy.



The book is broken up into four sections:

I. PLANNING TO WRITE
II. WRITING: GENERAL PRINCIPLES
III. WRITING: SPECIFIC KINDS OF DOCUMENTS
IV. EDITING AND PRODUCING DOCUMENTS

I. PLANNING TO WRITE
Other then an interesting example of creative technical writing in the first chapter, this section didn't offer me much, but it contains necessary information for a writer. If you have read anything on writing in the past (or have been successfully published), then odds are you are already aware of audience and how to plan your writing.

II. WRITING: GENERAL PRINCIPLES
This section was excellent. Like the previous section, this one contained basics. However, unlike the previous section, these basics need to be read over and over again. They are the building blocks of good writing. It contains practical advice - like the following simple advice on using verbs:


  • Choose strong verbs

  • Avoid overusing to be

  • Vary your verbs

  • Keep verbs in the same tense



And advice on causes of long sentences (my worst problem):

  • Jamming two or three ideas into a single sentence

  • Using passive voice

  • Being repetitious

  • Using words or phrases that don't pull their weight

  • Embedding lists that should be broken into bulleted or numbered lists



This section is required reading for me. I think I will try to re-read this section every couple of months. Each chapter in the book ends with a series of questions relating to the topics covered. At the very least I will use those questions when editing my work.

III. WRITING: SPECIFIC KINDS OF DOCUMENTS
This is the section that I think would be most useful to developers and testers. It takes a look at writing specific types of manuals:


  • cookbooks

  • tutorials

  • guides

  • references

  • nonverbal manuals

  • online help

  • release notes

  • glossaries

  • tables of contents

  • indexes

  • web sites

  • proposals

    • research proposals

    • book proposals

    • business plans

  • internal planning documents

  • lab reports



It also has an excellent section on giving presentations. I know that a lot of people in this community present at conferences, so I would recommend that section specifically (even though it has an initial focus on PowerPoint).

IV. EDITING AND PRODUCING DOCUMENTS
This section focuses on editing and the editing process. I think I pulled more useful information on editing from section II, but there is still good information here if you have never been through the process before. The most interesting tidbit I pulled from this section was the following comparison of punctuation to music and timing:


  • A comma is a quarter-note rest.

  • A dash is a half-note rest.

  • A semicolon is a three-quarter note rest.

  • A period is a full-note rest.



It's an example that's both meaningful and memorable. I think I've been using dashes incorrectly for the last four years.

The writing style for the book made it enjoyable to read. Rosenberg has a sense of humor and makes a rather dry topic interesting and fun to read. The fact that I read it in one weekend is a testament to that. It typically takes me weeks to work through a book on writing.
Good books on software testing
This year I read numerous books on software testing. Over thirteen books had the words 'testing' or 'test' in the title. Of all of these, only four of them were really good books:





Out of all thirteen, these were the only four I would recommend to someone who wanted to know about testing.

Most of the problems I found with the other books related to problems like the one I pointed out in Bad books on software testing. Things like universal statements about what testing is and what it should be. Or authors who list techniques for working in unrealistic project environments. Processes and documentation schemes that would make you cry if you actually implemented ALL of it. Or possibly it's the fact that most authors show little references to where their research comes from (if they have any at all). Finally, in the last few books I read I found an overwhelming amount of time spent with the waterfall development model (and subsequently the v-model).

So where is all the good information on software testing?

Not in books on software testing!

This year, the best books I read on software testing had nothing to do with testing. If you want a good book on the basics of exploratory testing, read Sometimes the Magic Works. If you want a book on performance testing, read To Engineer Is Human: The Role of Failure in Successful Design. Need to know more about usability testing, read The New Brain: How the Modern Age Is Rewiring Your Mind. If you want to become more effective in your role as a tester, read Amplifying Your Effectiveness. And if you want to be better equipped to understand your project environment, corporate culture, and the inner dynamics of your test team, read The True Believer: Thoughts on the Nature of Mass Movements.

I have concluded that most books on software testing are for people new to software testing. Of course this is purely anecdotal and based on the few books I have read (I do not claim to have an excessively large number of books on software testing).

I would however also point to a list of books recommended by Cem Kaner, James Bach, and Brett Pettichord. In Chapter Two of their book Lessons Learned in Software Testing, titled "Thinking Like a Tester", how many books on software testing do you think they recommend?

None.

They recommend:


Of all these books, only one of them could be argued to be a book on software testing.

With that in mind, I need some more good books on testing, and for the coming year I think I'm done reading books on testing. Can you recommend a good book? Please feel free to comment below.