I. M. Testy : Tester's Bookshelf

The Ultimate Desktop Reference

I.M.Testy — Wed, 24 Dec 2008 06:55:21 GMT

I have a library of books and white papers on software testing, engineering processes and management, and software development that I have read and reference quite often. For new testers I generally recommend A Practitioner's Guide to Software Test Design by Lee Copeland, and How to Break Software: A Practical Guide to Testing by James Whittaker. There are 5 books I highly recommend (not including How We Test Software at Microsoft which I co-authored and also highly recommend).

In my current role as a teacher, trainer, and mentor of new testers the 2 books that are constantly on my desktop are Testing Object-Oriented Systems: Models, Patterns, and Tools, by Robert V. Binder, and Software Testing Techniques, 2nd edition by Boris Beizer. Not that I don't frequently reference other books, but to me these are the quintessential books on the foundational knowledge of software testing techniques and methodologies for intermediate to advanced testers with a strong technical background.

But, the booklet that I would keep in my shirt pocket if I tested products on a day-to-day basis would be Josh Poley's Black Book. Josh's Black Book is the ultimate desktop reference for software testers (and developers). While this book is primarily intended to aid those who work on projects developed in C/C++, it has loads of information that is valuable to any tester working on just about any technology. From decimal and named entities of ISO characters to error codes for DOS, VB, JScript, HTTP, and of course Windows Errors this book is jammed packed with great information and quick reminders for both developers and testers.

Do testers do code reviews?

I.M.Testy — Tue, 11 Mar 2008 09:57:00 GMT

This weekend on the flight from Seattle to Ireland I finally got to catch up on some reading. One of the books I grabbed off the shelf that I hadn't gotten around to reading yet was Best Kept Secrets of Peer Code Review by Jason Cohen. The book is 160 pages packed with great information, and I highly recommend it for some fresh perspectives of the value or ideas on improving code reviews. For decades the industry collected mounds of empirical data that pretty clearly illustrates the value of code reviews in a software development lifecycle in the early detection and removal of issues and anomalies. With the industry wide push to drive quality upstream via approaches such as agile programming and test driven development there is a resurgence of effort by developers to engage in more frequent code reviews.

Many people seem assume the primary reason why Microsoft (and other companies) is recruiting more technically skills testers is simply to automate tests. But, in fact, many testers at the company engaged in writing test automation long before our efforts towards engineering excellence. The skills and knowledge that people who have a much deeper understanding of the 'system' bring to an organization extends well beyond their ability to write automation.

But, should testers be performing code reviews? In my opinion, code reviews are simply another approach in a myriad of approaches to testing a software project, and professional testers should be able to engage the testing effort from a variety of testing perspectives.

Testers who participate in project code reviews are part of the team effort to drive quality upstream, reduce certain classes of issues before they are checked into the build, improve overall long-term maintainability of the code base, and effectively reduce long term costs. Just as testers participate in the early stages of the design and requirements phase of a project to provide valuable input, some testers on every team should engage in code reviews either with other developers, or perhaps as the primary reviewers of project code. Some people will argue that testers may be biased by participating in code reviews and lose the 'customer' perspective. This may be true in some cases, but I suspect that most professional testers clearly understand the different classes of issues that are more easily found in a code review versus other approaches of testing. But, testers who engage in code reviews tend to have a much deeper understanding of the overall project, and they are also able to identify potential areas of the code that may be more problematic and focus additional testing approaches in those areas.

Tester's Guide to Gaining 'System' Knowledge

I.M.Testy — Thu, 10 May 2007 07:20:00 GMT

In retrospect, my father had the incredible foresight to introduce me to electronics at a young age. When I was in junior high we built a vacuum tube AM radio kit from Heathkit . That thing put out enough heat to warm a small apartment, but there was...(read more)

Are software metrics and measurements really important?

I.M.Testy — Mon, 20 Nov 2006 23:47:00 GMT

On a recent flight back from Boston to Seattle I decided to read Measuring the Software Process: A practical guide to functional measurements by David Garmus and David Herron. The book does a really good job of explaining functional points, what they...(read more)

Peopleware: A must read for everyone (especially managers)

I.M.Testy — Tue, 24 Oct 2006 21:22:00 GMT

I recently went to Portland, and when I am there I make it a point to always stop by Powells Book Store. They have a whole building about the size of a typical Barnes & Noble dedicated to technical books. It had been several years since I had read...(read more)

Programming basics for (non-coding) testers

I.M.Testy — Mon, 28 Aug 2006 03:44:00 GMT

I suspect one reason why many testers do not learn to read or write code is because they find the initial hurdle of learning a modern programming language insurmountable. But, there is a growing demand for testers with coding skills. As software grows...(read more)

Top 5 recommended books on software testing for new software testers

I.M.Testy — Tue, 02 May 2006 05:48:00 GMT

It now astounds me that some individuals can spend years in a testing role and never read a single book on the subject. I say 'now' because when I first started in software testing I hadn't read a book on the subject either. In fact, it wasn't until I...(read more)